13、深入理解事件驱动架构与消息总线的应用与演进

深入理解事件驱动架构与消息总线的应用与演进

1. 维护模拟对象的负担与事件的价值

在软件开发中，你可能会担心维护模拟对象会成为一项负担。不过实际上，一旦项目启动并稳定运行，仓库和工作单元（UoW）抽象的接口并不会有太大变化。如果使用抽象基类（ABCs），它们还能在出现不同步情况时提醒你。

领域事件为我们处理系统中的工作流提供了一种有效的方式。从领域专家那里，我们常常能听到以因果或时间顺序表达的需求，例如“当我们尝试分配库存但无货可用时，应给采购团队发送邮件”。“当X发生时，执行Y”这样的表述往往暗示着系统中可以具体实现的事件。将事件作为模型中的一等公民，有助于提高代码的可测试性和可观察性，还能分离关注点。

领域事件的优缺点如下表所示：
| 优点 | 缺点 |
| — | — |
| 消息总线在响应请求需执行多个操作时，能很好地分离职责。 | 消息总线需要额外的理解成本，工作单元触发事件的实现虽然巧妙但有些隐晦，调用提交操作时，可能不明显会触发邮件发送等操作。 |
| 事件处理程序与“核心”应用逻辑解耦，便于后续更改实现。 | 隐藏的事件处理代码同步执行，可能导致服务层函数在所有事件处理程序完成后才结束，从而在Web端点引发意外的性能问题，添加异步处理会使情况更复杂。 |
| 领域事件是对现实世界建模的好方法，可作为与利益相关者建模时业务语言的一部分。 | 事件驱动的工作流可能会让人困惑，因为请求被分散到多个处理程序中，系统中没有一个单一的地方能让你全面了解请求的处理方式。还可能出现事件处理程序之间的循环依赖和无限循环问题。 |

事件的用途不仅限于发送邮件。当需要在一个请求中更改多个聚合时，我们可以利用事件使它们