背景
上一篇文章分布式数据一致性思考-B端系统一致性 阐述了分布式系统一致性的做法，那么对应业务系统该如何设计呢？ 本篇讲解基于上一篇思路下的系统架构设计
架构图
根据DDD架构的分层思路，层级分别为
接口适配层
- 系统对外提供的rpc服务层，提供最基础的服务
- 监听其他系统消息，消息作为驱动入口
- 还有各种定时任务等入口，适配层会将请求信息转换成应用层需要的模型信息
应用层
- 负责具体业务实现与业务流程编排，更多的是作为编排者，通过领域服务层来实现业务逻辑
- 同时这里也会做最先的业务逻辑校验，业务校验需要快速失败，能前置的校验都可以先做
- 本层需要提供两个核心能力，校验引擎和流程引擎
校验引擎：
其实就是对业务校验共同的抽象，我们所有业务进行校验的时候通常会有共统的校验信息，比如店铺信息是否合法，商品状态 类目 类型等信息是否符合条件，这些校验信息可以原子化的抽取出来，一个校验器只做一件事情，然后不同的业务根据需要组装出自己的校验信息，不仅可以通用 也可以非常方便拓展
流程引擎：
之前文章也说过了一致性的思考，这种场景不仅适用于B端，C端场景也是适用的，通过流程引擎抽象出业务流程，将要做的事情进行原子化拆分，每个任务就做一件事情，做好这件事情可能涉及rpc调用或者db操作，注意这里是一件事情不是只能做一个事情，比如任务里面可以进行多个rpc调用然后进行db数据保存，只要业务上认为这里是最原子的都可以。
通过流程引擎可以知道一个业务场景做了哪些事情，至于并发控制和流程驱动就交给引擎层吧，业务上只需要根据自己的实际情况配置业务流程是否需要重试以及时间等，引擎层会自动捞取需要执行的业务流程。
很多情况执行任务的时候并不是马上能执行完成的，比如调用下游接口，下游是异步处理的，流程驱动需要通过下游消息触发推进，业务上收到消息后需要对消息回执处理然后继续流程，流程引擎当然也是支持这种场景的
流程引擎可以和校验引擎组合使用，在流程前进行必要的业务校验，统一抽象出来，这样应用层这个业务架构就确定了，不用担心每个人不同的代码风格导致整体项目复杂剧增了。
统一引擎之前,在应用层可以看到各种神仙代码，可能对业务层抽象都没有，就是一串的事务脚本代码
void doSmthing(){
bizA.xx1();
bizB.xx2();
// 触发 等待回调
bizC.xx3();
//xxx 各种逻辑
}
void doSmthingReceipt(){
bizC.xx4();
bizD.xx();
}
统一之后，整体框架流程确认，可以看到完整的业务流程，代码腐败也被控制到了任务这层
SmthingProcessor{
String[] getTask(){
return ["bizATask","bizBTask","bizCTask","bizDTask"];
}
}
//任务回调
commonProcessor.onReceipt(xx);
领域层
这层是领域服务核心，由领域模型，领域服务，领域事件，仓库等组成，这里只做领域服务核心事情，做自己最原子的事情，在领域模型发生变更时触发领域事件
状态机引擎放到了本层，对于领域对象来说状态的转变是固定的，由状态A做了事情B推进到了状态C，作为核心能力供应用层使用。
这一层需要精细打磨，设计好聚合根，不要简单的就是和表结构一一对应（已经看到好多了），对象是由属性和行为组成的，不要让自己的领域对象失去了灵魂。
基础层
本层提供了基础的应用服务，比如下游rpc服务，消息，db，缓存等和支撑业务系统能力。
总结
通过整体介绍其实本文最核心的应用层的流程引擎设计，通过流程引擎设计将任务拆分，每个任务做自己的一件事情，整个系统业务逻辑非常清晰，任务自驱动可以对业务流程进行重试，框架与业务隔离，框架的事情就让框架去做吧。新人也可以非常快速的熟悉，通俗易懂的设计是减少系统bug的关键。
为什么系统那么复杂？就是因为不懂整体代码，在某个角落加上了if逻辑，然后又在某个角落加个else逻辑，然后代码你都能看懂，就是不知道在干嘛=_=。