我是反对的, 请使用事务注解和ddd - 支付域使用的代码流程模板/事务模板进化史/流程引擎进化史/状态机进化史

父文章 收单系统(支付系统)总结 - 内含幂等,事务,状态的非常好的例子_个人渣记录仅为自己搜索用的博客-CSDN博客

事务需要模板来限制, 另外降低事务需要先读再处理. 再面向领域处理. 放到一个Context里.

模板 -> 当handler状态机 -> 多exectuor状态机. -> 自判断的流程引擎

模板1 (见下文) 简单一个事务模板仅一个事务操作, 且只能处理一个回滚Eception阻断. 无法处理多状态流转的问题.

模板2 复杂的事务模板, 支持多状态流转. 演化成状态机. 但仅支持一个handler. 通过handler的返回是否 stop ,死循环. 

模板3 更复杂的事务模板 支持阻断流转. 每个process均返回一个Tansfer类.   

模板4 最复杂的就是流程引擎- 有存在支持节点自判断流程,创建出不同的流程分支event. 也可以降级到模板3, 将三个流程即自判断(能否入金), 多个event(正常入金/异常挂账)降级成一个流程(入金流程). 参数验证,外部数据获取在事务之前 .  (但是只要依赖了下游的rpc,这些努力都白费,下游的组装和调用都在rpc内. ,还不如 领域实体校验,组装 .领域实体校验,组装 )
 

模板\	第一代模板	第二代模板	第三代模板	第四代模板
阻断事务回滚能力	*	*	*	*
分叉能力		n 依赖while循环	n	n
executors分割能力			有 每个executor都依赖statusTransfer判断. 框架里判断status转移合法性	有
节点自判断流程				有  根据节点和event 后的targetStatus来判断执行哪些流程,最终生成的领域实体是什么,哪些属性需要持久化. (得到那个event走入金还是挂账)

第四代模板的第一层切分?

  第一层按流程切分 ,那么每层里面,bizValidate/bizProcess都要判断targetStatus=入金 还是 挂账.  最终的领域类List<Transfer>要么是入金的transfer ,要么是挂账的transfer. 

  第一层按状态来分, 那么配置就会比较复杂. 每个target下,都有AssembleEntity,fillEntity的流程. 扩展性不好. 有可能在事务内的bizValidate阶段才知道走哪个链路. 事务内validate后才能组装领域实体.

  NOTE: 订单下面的transfer领域实体只能二选一,不能入金领域实体 , 挂账领域实体都生成, 通过key来区分. 持久化的时候也不知道持久化哪个. 在bizValidate阶段对requestValidate阶段就应该明确走哪个流程了.