DDD - 领域事件_解耦微服务的关键

文章目录

Pre
领域事件的核心概念
领域事件的作用
领域事件的识别
领域事件的技术实现
领域事件的运行机制案例
领域事件驱动的优势

在这里插入图片描述

Pre

DDD - 微服务设计与领域驱动设计实战(中)_ 解决微服务拆分难题

EDA - Spring Boot构建基于事件驱动的消息系统

领域事件的核心概念

领域事件（Domain Event）是领域驱动设计（DDD）中的一个重要概念，用于表示在领域中发生的、对业务有重要意义的事件。这些事件通常会导致进一步的业务操作，并且在微服务架构中，领域事件是实现微服务解耦的关键机制之一。

领域事件的作用

业务解耦：领域事件可以切断微服务之间的强依赖关系，发布方只需发布事件，而不需要关心订阅方的处理结果，从而实现微服务之间的解耦。
业务闭环：领域事件有助于形成完整的业务闭环。通过事件驱动的方式，业务流程可以在不同的微服务之间流转，确保业务的连续性和一致性。
最终一致性：在微服务架构中，领域事件通常采用最终一致性，而不是强一致性。这种方式可以减少分布式事务的使用，提升系统的性能和可扩展性。

领域事件的识别

在业务分析过程中，可以通过以下关键词来识别领域事件：

“如果发生……，则……”
“当做完……的时候，请通知……”
“发生……时，则……”

这些场景中的事件通常会导致进一步的业务操作，因此可以被识别为领域事件。

介绍一个保险承保业务过程中有关领域事件的案例。一个保单的生成，经历了很多子域、业务状态变更和跨微服务业务数据的传递。这个过程会产生很多的领域事件，这些领域事件促成了保险业务数据、对象在不同的微服务和子域之间的流转和角色转换。
在下面这张图中，列出了几个关键流程，用来说明如何用领域事件驱动设计来驱动承保业务流程

在这里插入图片描述

事件起点：客户购买保险 - 业务人员完成保单录入 - 生成投保单 - 启动缴费动作

投保微服务生成缴费通知单，发布第一个事件：缴费通知单已生成，将缴费通知单数据发布到消息中间件。收款微服务订阅缴费通知单事件，完成缴费操作。缴费通知单已生成，领域事件结束。
收款微服务缴费完成后，发布第二个领域事件：缴费已完成，将缴费数据发布到消息中间件。原来的订阅方收款微服务这时则变成了发布方。原来的事件发布方投保微服务转换为订阅方。投保微服务在收到缴费信息并确认缴费完成后，完成投保单转成保单的操作。缴费已完成，领域事件结束。
投保微服务在投保单转保单完成后，发布第三个领域事件：保单已生成，将保单数据发布到消息中间件。保单微服务接收到保单数据后，完成保单数据保存操作。保单已生成，领域事件结束。
保单微服务完成保单数据保存后，后面还会发生一系列的领域事件，以并发的方式将保单数据通过消息中间件发送到佣金、收付费和再保等微服务，一直到财务，完后保单后续所有业务流程。这里就不详细说了。

总之，通过领域事件驱动的异步化机制，可以推动业务流程和数据在各个不同微服务之间的流转，实现微服务的解耦，减轻微服务之间服务调用的压力，提升用户体验。

领域事件的技术实现

领域事件的执行需要一系列的组件和技术来支撑。我们来看一下这个领域事件总体技术架构图，领域事件处理包括：事件构建和发布、事件数据持久化、事件总线、消息中间件、事件接收和处理等

在这里插入图片描述

领域事件的技术实现通常包括以下几个步骤：

事件构建和发布：
- 事件的基本属性包括事件唯一标识、发生时间、事件类型和事件源。
- 事件的业务属性记录事件发生时的业务数据，这些数据会随事件传输到订阅方。
- 事件发布可以通过应用服务、领域服务或消息中间件来完成。
事件数据持久化：
- 事件数据持久化可以用于系统之间的数据对账或审计。
- 事件数据可以持久化到本地业务数据库的事件表中，或者持久化到共享的事件数据库中。
事件总线（EventBus）：
- 事件总线是微服务内聚合之间领域事件的重要组件，负责事件的分发和接收。
- 事件总线可以同步或异步地传递数据，确保事件在微服务内外的订阅者之间正确传递。
消息中间件：
- 跨微服务的领域事件通常使用消息中间件（如Kafka、RabbitMQ）来实现事件的发布和订阅。
- 消息中间件可以确保事件在微服务之间的可靠传递。
事件接收和处理：
- 订阅方通过监听机制接收事件数据，并将其持久化到本地数据库。
- 订阅方在领域服务中处理事件，完成后续的业务操作。