作为一个优秀的程序员，要守住职业的底线。能简单快速的完成的一件事，就一定要用简单的方案快速完成。不可过度的设计，始终保持系统的简洁！
曾几何时，我对于流程编排这件事 嗤之以鼻，为什么呢？我认为流程编排是典型地过度设计。
在我看来，代码越直观越可靠，我不喜欢看代码的时候跳来跳去。但是流程编排后，要把各个方法放到扩展类，通过组合各个扩展类新建一个流程，实现业务功能，这能有什么好处呢？
直到我来到一个中台团队，才意识到流程编排能力是保命的能力。
业务中台要接入很多的业务方，每个业务方并不是完全相同。很多时候无法完全复用，需要改造系统适应新的业务。
新增业务代码时，务必要保证原有业务不受影响，如果没有流程编排能力，就会充斥大量的 if else 。
if (biz == BizA || biz == BizB) {
//do some thing
//这部分逻辑相同
if (biz == BizA) {
//差异化处理
}
if(biz == BizB) {
//差异化逻辑
}
}
例如上面的代码，不同的业务线若有差异化逻辑，需要新增分支单独处理。想象一下，当有 10 多个业务接入了你的系统，那么一定让人抓狂……
任何一个人都无法保证对 10 多种业务完全熟悉，每个人可能只负责 1 个业务，然而如果没有代码逻辑的隔离，维护者只能在千丝万缕中，才能找到目标代码逻辑。更可怕的是，每次新增一个业务，需要在原有的屎山中继续💩，不断新增 if else。直到有一天，有一个倒霉蛋改错了代码，导致其他重要业务受影响，引发线上故障。
想象一下，当你改了几行代码以后，要求测试同学，回归10 多个业务线的全部逻辑？这显然不现实。
以上的问题和痛点可归纳为：代码隔离性和业务扩展点问题。解决这两类问题有如下手段！
MemberClub 中大量使用流程引擎和插件扩展引擎解决业务隔离性和扩展性 问题。
MemberClub是托管在Gitee平台的开源项目，提供了付费会员的交易解决方案，在各类购买场景下提供各类会员形态的履约及售后结算能力，具体介绍可参见
https://gitee.com/juejinwuyang/memberclub
配置流程执行链
考虑到不同的会员产品交易提单流程不同，不同的产品应配置不同的流程，
DemoMemberPurchaseExtension
实现了购买扩展点，并且定义了三个流程执行链的配置方式。如截图所示~
定义流程节点
流程节点中的方法包括
process
、
success
、
rollback
和
callback
方法。
流程执行
流程执行时 需提供流程上下文对象。调用
FlowChain.execute
方法即可
实际执行阶段，各个流程节点被流程引擎串联起来依次执行，类似于责任链的设计模式，具体执行顺序如下图所示。
依次执行每个流程节点的
process
方法，若
process
方法出现异常，则执行
rollback
方法。若所有的
process
方法执行成功，则倒序依次执行
success
方法。
流程引擎执行原理
以下是
FlowChain.execute
方法执行原理。
public void execute(FlowChain chain, T context) {
Exception exception = null;
int
