[DDD]领域驱动设计 高级篇

[supergem3000]

领域事件：解耦微服务的关键

领域中发生的事件。一个领域事件将导致进一步的业务操作。 领域事件用最终一致性，不是传统SOA的直接调用。 聚合的一个原则：一个事务中最多只能更改一个聚合实例。所以

• 本地限界上下文中的其他聚合实例便可以通过领域事件的方式同步
• 用于使远程依赖系统与本地系统保持一致。解耦本地系统和远程系统还有助于提高双方协作服务的可伸缩性。 领域事件驱动切到领域模型之间强依赖关系。事件发布后，不关心订阅方事件处理是否成功，即可实现领域模型的解耦，维护领域模型的独立性和数据一致性。映射到微服务架构时，领域事件可解耦微服务，微服务间的数据不必要求强一致性，而是基于事件的最终一致性。

  感觉有些不太好理解。问了一下Copilot，大概意思就是中间短时间内运行数据不一致，但是最终会自动修复不一致状态。

微服务内的领域事件 不一定需要消息中间件，可以考虑事件总线。 微服务之间的领域事件 考虑事件发布和订阅、消息中间件、服务调用、分布式事务等。

领域事件总体架构

事件构建和发布 事件基本属性至少包括：唯一标识、发生时间、事件类型、事件源。 事件基本属性和业务属性一起构成事件实体。 事件发布之前需要先构建事件实体并持久化。

事件数据持久化 用于系统之间数据对账、发布方订阅方数据审计。如遇宕机等问题，可等解决后继续后续业务流转，保证数据一致性。 持久化有两种方案：

• 持久化到本地业务数据库的事件表，利用本地事务保证业务和事件数据的一致性。
• 持久化到共享的事件数据库中。注意由于跨数据库，需要分布式事务机制保证业务和事件数据一致性，可能对性能有影响。

事件总线 微服务内聚合之间事件分发和接收。

消息中间件 跨微服务的领域事件发布和订阅。如Kafka、RabbitMQ。

事件接收和处理 监听，接收事件数据，完成事件数据持久化，开始进一步业务处理。

DDD分层架构

用户接口层、应用层、领域层和基础层 应用层应该很薄，主要面向用例和流程相关操作。应用层是微服务之间交互的通道，可以调用其他微服务。不要将本应放在领域层的逻辑放到应用层，时间长会又演化为传统的三层模型。 领域层实现核心业务逻辑，包含聚合根、实体、值对象、领域服务等领域对象。