【按】“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)。ÿ