《DDD实战课》读书笔记二（领域事件）

概述

• 在DDD中除了命令和操作等业务行为外，还有一种事件，这种事件发生后会导致进一步业务操作，这种事件叫做领域事件。
• 领域事件是领域模型中非常重要的一部分，用来表示领域中发生的事件。一个领域事件将导致进一步的业务操作，在实现业务解耦的同时，还有助于形成完整的闭环。

领域事件识别

• 业务、需求或领域专家的关键词：“如果发生…则…”，“当做完…的时候，请通知…”，“发生…时，则…”。这些场景中，如果发生某件事件后会触发进一步的操作，这个事件就很可能是领域事件。
• “在边界之外使用最终一致性”是聚合的一个设计原则，一次事务最多只能更改一个聚合状态。如果一次业务操作涉及多个聚合状态的修改，就需要使用事件的最终一致性。
• 领域事件有的发生在微服务或模块内的聚合之间，有的发生在微服务或模块之间，处理也需要采用不同的方式进行处理。

微服务或模块内的领域事件

• 领域事件发生后完成实体构建和事件数据持久化，发布方聚合将事件发送到事件总线，订阅方接收并完成后续操作。
• 微服务内大部分事件都在同一进程，不需要引用消息中间件，就需要考虑是否引入事件总线或分布式事务。
• 事件总线可能会增加开发复杂度，所以需要结合应用复杂度和收益进行综合考虑
• 分布式事务适用于实时性和数据一致性要求高的场景，需要保证发布方和订阅方的数据同时更新成功。

微服务或模块间的领域事件

• 领域事件发生在微服务之间，事件处理机制更复杂。跨微服务事件可以推动流程或数据在不同子域或微服务间直接流转
• 跨微服务的事件机制要总体考虑事件构建、发布、订阅，事件数据持久化、消息中间件甚至事件数据持久化还需要引入分布式事事务机制。
• 跨微服务数据需要同时变更时需要引入分布式事务保证数据一致性。分布式事务机制影响性能，增加耦合度尽量避免使用。

领域事件总体架构

• 领域事件处理包括：事件构建和发布，事件数据持久化、事件总线、消息中间件、事件接收处理等。

事件构建和发布

• 事件基本属性主要包括：事件唯一标识，发生时间，事件类型和事件源。
• 事件基本属性和业务属性构成事件实体，事件实体依赖聚合根。
• 事件发布前需要先构建事件实体并持久化。可以通过应用服务或领域服务发布到事件总线或消息中间件，也可以使用定时程序或数据库日志捕捉及时获取增量事件数据，发布到消息中间件。

事件持久化

• 事件持久化可以用于系统间数据对账，或者数据审计。
• 时间持久化方案，有两种，根据场景选择使用哪种。
  – 持久到本地业务库事件表，利用本地事务保证业务和事件数据一致。
  – 持久到共享事件库，业务库和事件库不在同一数据库中，持久化会造成跨库就需要用分布式事务保证业务和事件数据一致。

事件总线

• 事件总线是进程内模型，会在微服务内聚合间便利订阅者列表，采用同步或异步模式传递数据。事件分发流程大致如下
  – 如果微服务内其他聚合的订阅者，直接分发到指定订阅者。
  – 如果是微服务外订阅者，将事件保存到库中并异步发送消息中间件。
  – 如果同时存在服务内和服务外订阅者，先发送内部订阅者，将事件保存到事件表，再异步发送消息中间件。

消息中间件

• 时间上比较成熟的消息中间件，如kafka、rabbitmq等。

事件接收和处理

• 微服务订阅方采用监听机制，接收数据并完成数据持久化后在进行业务处理。