中台过气、微服务回归单体，DDD的意义何在？( 四 )_DDD

清楚微服务架构的同学一定知道：微服务架构设计的难点之一是拆分服务的力度大小，拆多了会导致运维难度呈指数提高，拆少了又回到了单体架构的模式、不够灵活，中间这个度就需要一种方法论来指导，而这个方法论就可以是领域驱动。对比领域分析模型和微服务架构，你会发现其实都是相互对应的，只是一种是从业务角度出发描述问题，一种是从技术实现角度描述问题，而这也是理论和实践的一种结合。

文章插图
2、合并的最佳实践：领域事件
在描述业务的过程中，往往会有这样一种描述：当某种事件发生后，会触发后续的事件或者用户进一步的行为操作，在领域驱动中会把这种有明显先后因果逻辑的事件称之为领域事件。
在领域事件中，会发现不同事件往往属于不同的领域服务之间，比如用户在购买物品支付成功后，会触发发货流程，这里的支付和发货就属于不同的领域，并在逻辑上有先后的顺序。
针对以上事件，领域驱动提倡：领域事件的数据通信方式使用事件发布订阅的方式进行，不直接同步调用，而事件发布的本质则是一种低耦合的异步数据沟通方式。
同步调用有两点需要考虑的问题：分布式事务以及时耗。针对事务问题一般需要引入第三方组件或者在业务层处理各种超时失败等异常的场景，可以说相当的复杂，维护成本也很高；而在分布式系统中时耗问题会被放大，一个请求可能跨越十几个甚至几十个服务，高并发的场景下，超时的风险会增大，上游的接口可能会被拖死。这都是同步调用需要考虑的问题。
在领域事件这种场景下，有一个更好技术选择，则是使用事件发布订阅的方式，还是拿用户购买物品支付发货场景为例，看看其实现过程：

用户支付下单后，支付域创建事件，持久化事件状态，在支付成功后发布事件，支付行为结束。
发货域订阅支付事件，在收到用户支付成功事件后，触发用户所购买物品的发货，持久化事件状态并结束。
用户收到发货成功通知，等待收货。

文章插图
领域事件的本质其实是通过分析用户旅程找到领域之间的因果逻辑链，再通过事件发布订阅机制去实现流程上的解耦合。
那我们如何找到领域事件呢？一种最佳的实践是在领域专家的主导下项目相关的同学一起进行头脑风暴，联想和关联到和业务有关的所有事件，但是这里的难点并不是如何发散，而是发散后如何收敛事件，收敛的本质是对于事件的有效分类，这需要可以洞悉业务本质的人才可以做到，所以这就是为什么领域驱动中有一种角色叫领域专家，这个过程我也用图来表示。