背景
如何选择一个合适的审批流程，决定了业务逻辑的复杂度。因此选择合适的审批实现方式很重要。在售后，流程式的代码也较多，因此需要选择一个合适的方式。
一、需求
比如当前的流程存在多个步骤，每个步骤都需要人审批，此时的设计方案如何设计比较好？
二、方案
方案一：
这种模式适用于固定流程和可变长短流程
是基于当前的步骤，建立审批流，比如Activiti、Flowable或者阿里开源的审批流框架等，这个时候，此时每个判断条件放在审批流的排他网关上，也即左右变量上，解决流程上的繁琐判断。但是这样有一个问题：需要有一个专门管理的审批流来管理流程。由于审批流和角色挂钩，因此不免需要和认证中心做交互。如果当前的审批流程比较长，会出现一个问题，审批中心出现异常，我们的审批信息也需要进行回滚。由于审批中心和业务系统不在同一个服务，属于不同的领域，因此需要使用分布式事务来保证事务。这个成本上，会有点大。通常审批流较短的话，使用审批流框架比较方便。
方案二：
这种模式适应于固定流程和长度可变流程。
采用数据库预置全流程的方式，此时全流程事先插入到数据库，此时每个流程都会带上角色信息、金额、类型信息。也即比如根据金额和类型，查询对应的流程的步骤。然后将其待处理流程插入到数据库中。当轮到那个角色审批的时候，就进行对应的审批行为，进行审批。此时不需要审批流框架的加持也能完成这个过程。
改进方式：
但是这种方案还是不够灵活。由此我想到还有一种方式可以实现这种操作。也即在每次插入数据库前，将每个待审批的流程数据结构设计成json的数据结构，json里面带分支状态，结合状态来判断，这样每次执行完成，再增加一个总的状态，这样每次执行完成，就代表这个过程成功了，否则回退一个状态即可。
由于json数据结构，方便扩展，因此每次操作的过程还可以带上sort这个字段，这样方便排序的同时，还方便状态的标注。
出现异常与方案一相比，方便回滚。不会存在分布式事务的问题。
但是方案二有一个问题，就是出现多分支的时候，需要给定一个排序的字段。借助一些属性信息来区分。但是方案一对于多分支的情况，依然适用。
方案三：
通常基于审批流程，如果是固定的，可以基于责任链模式，来设计审批流程。责任链模式最典型的代表就是Sentinel。基于SPI构建出来的典型固定流程的设计模式。其本质类似于链表的数据结构。
三、可视化
当然对于这种模式，最好是有一个界面能够进行维护，这样方便可视化。可视化界面减少运维成本。同时能够带上开关，避免因为流程带来的问题。
四、总结
三种方案，各有各的好，但是相对成本而已，方案二的成本要比方案一的成本要低一些 同时方便维护。但是如果是同一级多分支的情况下，使用专业的工作流更为合理。如果当前的审批比较固定，则选择方案三更为合理，成本小，易于维护。
