“极客时间”《DDD 实战》课程笔记 （二）领域事件与微服务

发表于2020-02-18，长度950， 64个单词， 2分钟读完

---

这是一系列学习笔记，对象是 极客时间 上面的收费课程 《 DDD实战 》。上一篇笔记介绍了学习这门课的动机：DDD 是解决微服务系统的最佳实践。这一篇我记录一下关于领域事件的知识点。

在极客时间的课程里，这属于进阶概念了。基础概念我不在这说了，可以参考之前系列的《领域驱动设计DDD入门》2 至 5

识别领域事件

捕捉业务、需求人员或领域专家口中的关键词：“如果发生……，则……”“当做完……的时候，请通知……”“发生……时，则……”等。在这些场景中，如果发生某种事件后，会触发进一步的操作，那么这个事件很可能就是领域事件。

微服务内的领域事件

领域事件发生后完成事件实体构建和事件数据持久化，发布方聚合将事件发布到事件总线，订阅方接收事件数据完成后续业务操作。

一个事件可能同时更新多个聚合，按照 “一次事务只更新一个聚合”的原则，要考虑是否引入事件总线。但微服务内的事件总线，可能会增加开发的复杂度。

微服务之间的领域事件

跨微服务的领域事件会在不同的限界上下文或领域模型之间实现业务协作，其主要目的是实现微服务解耦。要总体考虑事件构建、发布和订阅、事件数据持久化、消息中间件，甚至事件数据持久化时还可能需要考虑引入分布式事务机制等。

总体架构

1. 事件构建和发布

事件发布之前需要先构建事件实体并持久化。事件发布的方式有很多种，可以通过应用服务或者领域服务发布到事件总线或者消息中间件，也可以从事件表中利用定时程序或数据库日志捕获技术获取增量事件数据，发布到消息中间件。

2. 事件数据持久化

事件数据持久化有两种方案：

• 持久化到本地业务数据库的事件表中
• 持久化到共享的事件数据库中

3. 事件总线

事件总线是实现微服务内聚合之间领域事件的重要组件，它提供事件分发和接收等服务。

• 如果是微服务内的订阅者（其它聚合），则直接分发到指定订阅者；
• 如果是微服务外的订阅者，将事件数据保存到事件库（表）并异步发送到消息中间件；
• 如果同时存在微服务内和外订阅者，则先分发到内部订阅者，将事件消息保存到事件库（表），再异步发送到消息中间件。

4. 消息中间件

跨微服务的领域事件大多会用到消息中间件。

5. 事件接收和处理

微服务订阅方采用监听机制，接收消息队列中的事件数据，完成事件数据的持久化后，就可以开始进一步的业务处理。

Written on February 18, 2020

分类： dev， 标签： ddd

---

• 分享到
• 
• 
• 
• 
• 
• 
• 

如果你喜欢，请赞赏！