第二部分:事件驱动架构
我很抱歉很久以前为这个主题创造了“对象”这个术语,因为它让很多人专注于次要的想法。
核心思想是“消息传递”。……构建伟大且可扩展系统的关键更多在于设计模块之间的通信方式,而不是模块的内部属性和行为应该是什么。
— Alan Kay
能够编写一个领域模型来管理单个业务流程的一部分固然很好,但是当我们需要编写多个模型时会发生什么?在现实世界中,我们的应用程序位于组织内部,需要与系统的其他部分交换信息。您可能还记得我们在 但是,所有这些系统将如何相互通信呢? 中显示的上下文图。
面对这一需求,许多团队求助于通过 HTTP API 集成的微服务。但是,如果他们不小心,最终会产生最混乱的局面:分布式大泥球。
在第二部分中,我们将展示如何将 [第一部分] 中的技术扩展到分布式系统。我们将放大视野,看看如何从通过异步消息传递交互的许多小组件构建系统。
我们将看到我们的服务层和工作单元模式如何使我们能够重新配置我们的应用程序以作为异步消息处理器运行,以及事件驱动系统如何帮助我们将聚合和应用程序彼此解耦。

图 1. 但是,所有这些系统将如何相互通信呢?
我们将研究以下模式和技术
- 领域事件
-
触发跨越一致性边界的工作流程。
- 消息总线
-
提供一种从任何端点调用用例的统一方法。
- CQRS
-
在事件驱动架构中分离读取和写入避免了尴尬的折衷,并实现了性能和可扩展性的改进。
此外,我们将添加一个依赖注入框架。这本身与事件驱动架构无关,但它整理了很多遗留问题。