DDD实战课（2）：进阶篇

进阶篇：常见的微服务架构模型以及中台设计思想

06 | 领域事件：解耦微服务的关键

参考：理解领域事件
《实现领域驱动设计》领域事件章节

领域事件：领域模型/微服务之间的事件

领域事件：捕捉业务、需求人员或领域专家口中的关键词：“如果发生……，则……”“当做完……的时候，请通知……”“发生……时，则……”等。在这些场景中，如果发生某种事件后，会触发进一步的操作，那么这个事件很可能就是领域事件。

举例：领域事件可以是业务流程的一个步骤，比如投保业务缴费完成后，触发投保单转保单的动作；也可能是定时批处理过程中发生的事件，比如批处理生成季缴保费通知单，触发发送缴费邮件通知操作；或者一个事件发生后触发的后续动作，比如密码连续输错三次，触发锁定账户的动作。

领域事件驱动设计

领域事件一般用在微服务/领域模型之间，切断领域模型之间的强依赖关系，通过领域事件来驱动业务的流转。领域事件需要保证一次事务最多只能更改一个聚合/领域的状态。如果一次业务操作涉及多个聚合/领域状态的更改，应采用领域事件的最终一致性。

跨微服务的事件机制要总体考虑事件构建、发布和订阅、事件数据持久化、消息中间件，甚至事件数据持久化时还可能需要考虑引入分布式事务机制等：微服务之间的访问可以采用应用服务直接调用的方式（RPC等），实现数据和服务的实时访问，弊端就是跨微服务的数据同时变更需要引入分布式事务，以确保数据的一致性。分布式事务机制会影响系统性能，增加微服务之间的耦合，所以我们还是要尽量避免使用分布式事务。

一个微服务/领域模型在事件发布完成时，即完成了事件实体构建和事件数据持久化。领域模型内发布方聚合将事件发布到事件总线。身份为订阅方的领域模型在接收到事件后触发后续业务操作。发布方不必关心后续订阅方事件处理是否成功，实现了领域模型之间的解耦，各个领域模型各自维护领域内数据的强一致性（一个领域事件只涉及到一个聚合的修改，聚合内部的强一致性必须得以维护），通过领域事件实现领域之间数据的最终一致性（涉及到其他聚合的修改时，通过发布事件的方式通知订阅方，订阅方在接收到消息后完成自己内部数据一致性的维护，从而实现了不同领域之间的最终一致性）。

无论是微服务内部还是之间，只要业务涉及到多个聚合/领域的更新，就可能会借助领域事件，引入领域事件则必然意味着聚合之间不再遵守强一致性，而是遵守最终一致性。

在业务操作和事件发布之间我们依然需要采用强一致性，也即这两者的发生应该是原子的，要么全部成功，要么全部失败，否则最终一致性根本无从谈起。以“订单积分”为例，如果客户下单成功，但是事件发送失败，此时就应该整体回退&#