DDD诊所——异步事件综合征

【按】“DDD诊所”是Thoughtworks DDD社区的一项活动，通过对同事们在实施DDD过程中遇到的问题进行分析和解答，共同提高开发水平。我们将其中一些典型案例整理成文供大家参考。之后也会考虑在适当的时候将这一形式对外部开放。

就诊日期：2021年11月1日

患者：某零部件管理系统

诊金：0元（免费义诊）

【患者主诉】

• 某制造企业为其经销商的售后部门开发了售后服务平台。本系统是该平台中的“零件”部分，服务于售后业务的“零件部门”。零件部门的业务包括售后单的零件准备、零件外销、零件采购以及零件管理等，目前采用微服务架构。患者的监护人从之前的团队接手该系统后，发现了一系列问题。
• 患者监护人梳理了当前系统的架构（主要是微服务间的关系），发现系统已经成了一个大泥球。架构图如下所示。

• 大量异步事件导致系统难以维护
• 系统存在数据不一致性以及莫名其妙的性能问题
• 在实现层面，同时采用了 Spring内置的事件总线和Message Queue两个机制。发布消息时，先发布一条Spring Event，Spring Event 的监听器再发消息到MQ。也就是说所有注册监听的服务都当做进程内的Spring Event处理，再由Spring和MQ打交道。如下图。

【病理分析】

患者的病情还是比较复杂的，需要几个方面的综合治疗。但这次就诊时间有限，于是医生首先询问了患者的监护人，哪个问题是最紧迫的。监护人认为是异步事件机制。所以这次集中分析这个问题。（为了讨论方便，本文假定微服务和限界上下文是一一对应的，会将两者混合使用，不做区分。两者不一一对应的情况将在以后另文分析。）

“图1 当前系统架构”中有大量的MQ（消息队列），所以我们首先怀疑患者很可能过渡使用了异步事件。当然还需要通过进一步诊断来求证。

很多朋友知道，领域事件是DDD领域模型的重要组成部分，又看到很多大厂大量采用了异步机制来处理领域事件，而一些书上也强调了异步机制的使用，因此就认为采用异步机制处理领域事件是理所当然的。那么这种理解完全正确吗？让我们从头说起。

“领域事件是DDD领域模型的重要组成部分”这一点是完全正确的。事实上，在Evans 2003年的《领域驱动设计》一书中并没有提领域事件。但在DDD之后的发展过程中，很多专家指出了领域事件的重要性。在2015年，Evans又写了一本小册子“Domain-Driven Design Reference”简要总结了DDD中的各个模式，在其中增加了领域事件（Domain Events）。