领域驱动设计戏说廿五篇，领域事件如何巧妙演绎？

本文共计7590个文字，预计阅读时间需要31分钟。

任何事物都在变化中，包括领域驱动设计。Evans首次提出DDD概念后，陆续出现了许多专家和学者对其理论进行扩充和比较，例如领域事件、事件源、命令等。

　　任何事物都在变化着包括领域驱动设计这门学问。Evans在首次提到DDD概念后，后来出现了陆续又出现了很多的专家与学者对其理论进行了扩充比如：“领域事件”、“事件源”、“命令查询责任分离”等。也正是由于这些补充，不仅让DDD的适用范围变得更大也让后来出现的微服务架构系统受益良多，为系统落地提供了非常优秀的理论指导。这节我们主要讨论领域事件，不夸张的说，在现代化的业务系统中它的应用普度度非常高，将其看成一种事实上的标准也并不为过。尤其在使用基于Saga的分布式事务时，领域事件完全是不能少的。此外，DDD中不推荐一个事务更新多个聚合，那如果有这种需要的时候要怎么做呢？答案还是“领域事件”，所以让我们开始今天的学习之旅。

一、概览

　　主流的基于事件的业务处理流程大概如下图所示。为什么说是主流呢？有些特殊情况下可能会使用多线程+远程服务调用的方式进行事件的投递，但这种情况大多都发生在遗留的系统中。很多系统中早已经引入了消息队列中间件或者一些消息队列组件，使用它们作为消息的载体已经是主流。所以后续的内容中一旦涉及到消息的投递我们默认就是指使用消息队列 。

　　单体时代，想要实现模块间的交流最简单的方式是通过进程内函数调用，比较直观，程序员用起来也更方便。到了微服务的时代，由于业务被划分到多个独立部署的服务中，想要实现业务串联方式之一是使用进程间通讯技术比如RPC或基于HTTP调用。