软件设计视角下：判断业务流程纳入自研系统还是采用BPM实现的标准有哪些？

判断标准 #

• 域归属属性
  若流程属于核心业务域的固有能力，和域逻辑强绑定、无法脱离对应域独立存在，应作为自研系统的一部分实现。例如电商交易域的订单履约核心逻辑、HR域的考勤抵扣规则，本身就是对应域的核心能力，拆分到BPM会破坏域内聚性，额外增加跨系统调用成本。
  若流程属于跨域协同规则，本身不属于任何单一业务域的核心能力，仅负责串联多个域的执行顺序、分支判断、异常处理逻辑，适合通过BPM实现。例如休假申请流程本身不是HR域的核心能力，只是串联员工提交、经理审批、考勤核算、薪酬调整多个节点的协同规则，调整流程不需要修改HR核心域逻辑，放在BPM灵活度更高。
• 变更频率
  若流程逻辑是业务固有规则、几乎不会变更，应放在自研系统内部实现。例如售后流程中“退货必须先确认用户已签收”的前置规则，属于业务固定约束，直接写在售后域逻辑里性能更高、逻辑更连贯。
  若流程规则需要频繁调整，且调整要求不发版即可快速生效，适合通过BPM实现。例如企业费用报销审批流，常随组织架构、费用类型调整审批层级、审批条件，用BPM的可视化配置能力修改后可直接生效，不需要迭代财务核心系统。
• 执行主体属性
  若流程全为系统自动执行节点、无人工干预环节，应放在自研系统内部实现。例如用户下单后的自动优惠券核销、积分扣减流程，全为系统自动操作，放在交易域内部实现链路更短、性能更稳定。
  若流程存在大量人工节点，且节点的操作权限、可见字段、操作人规则常调整，适合通过BPM实现。例如合同审批流程，需经过多角色人工审批，不同节点的操作权限差异大，用BPM的表单、权限配置能力实现灵活度更高。

实践建议 #

• 采用「核心域内聚逻辑 + BPM流程编排层」的分层架构，不要做非此即彼的选择：所有业务规则、数据操作逻辑全部收敛在自研业务域系统内，仅暴露标准化调用接口；BPM层仅负责流程路由、人工任务分发、跨系统接口编排，不实现任何业务规则，避免逻辑碎片化。
• 绝对避免逻辑重复实现：同一业务规则仅能在自研业务域系统中存在一份实现，BPM层只能调用对应接口，不允许重复编写相同逻辑，避免两侧规则不一致带来的业务故障。
• 边界模糊时优先收敛到自研系统：如果暂时无法判断某段流程逻辑的归属，优先放在对应业务域系统中实现，后续确认该逻辑属于高频调整的跨域协同规则时，再抽离到BPM层，反向迁移的成本远高于正向抽离。

注：以上结论均不考虑成本因素，仅从软件设计合理性角度给出。

内容的提问来源于stack exchange，提问作者Anyname Donotcare