流程引擎改造, 佬们支支招, 给点思路

flowable可以，我们公司在用，已经推广出去了

springboot4.1+java25性能提升不少，既然打算换架构还是独立服务，不如一步到位

最近正好在开发一个流程引擎项目，我选择的Camunda8+bpmn-js还在开发中 ^-^

对比看下来, 感觉上 flowable 更适合java业务项目一点

性能让客户机器加配置哈哈哈, 开玩笑的, 主要想偷懒一下, 独立服务要考虑更多东西就比较难受, 太拼了

对，当时我们也改造了两个月，配合低代码一起使用

Camunda8, 搞成分布式好像对我来说一致性要考虑的有点多, 偷懒我就没选了, 佬是怎么解决和业务数据一致性的问题的, 我这边好像很难保证别人写的接口是幂等的

你们改造了2个月阿, 那我搭个架子起来感觉找点人了要哈哈哈哈

外包项目还主动给做重构，很有爱心了

哈哈哈哈主要太多bug了, 天天流程修复太烦了, 打开代码就想喷.

我感觉半外包性质吧, tob的行业, 定制化二开, 也算是甲方的狗呜呜呜

一样的 .net 转 java 工作流引擎重构，不直接引入开源组件，只引入设计理念，同时兼容就有数据设计结构，最小时间成本，同时最小学习成本。

对于一些不能保证幂等的，只能把一些未知结果记录了，或者让对方提供接口查询，记录了后续人工处理，这是没办法的事情。

原来是这个“流程引擎”，想想也没少做，怎么这两就不那么眼熟。。。好吧Java+企业流程。 ^-^感觉跟人打交道的都累。

我焯, 佬你好猛, 我都不想阅读旧代码了已经, 想直接整个扔掉, 到时候双引擎, 用一阵子直接把旧的扔掉

哈哈哈哈哈是吧, 跟人打交道太累了, 企业流程又总是碰到傻福有天才想法

java和springboot应该用最新的长期支持版,flowable,activiti,camunda本身是没什么区别,我们采用的activiti做了些魔改来适配动态表单的配置

考虑到原有团队成员的学习成本和开发效率，同时旧代码也是有可取之处，虽然设计上可能过时，但业务沉淀还是有很大的价值，还是建议先古法搬一遍，摸透了，后续无论扩展还是优化都会避免很大的问题，并且现在 AI 虽然强大，但是还是要时刻人工介入，给 AI 指引方向，这方面还是要有点技术水平去支撑。

那作为一个傻福有天才想法的时候怎么判断是不是真的有用，还是说傻福就不可能有天才想法，有天才想法就不是傻福

佬，你们使用这个流程引擎是做业务审批，还是做业务逻辑流转的呢