如何运用领域驱动设计 - 领域事件

开篇

距离发布上一篇该系列的文章好像已经过了快一个半月了，好吧，我托更了😭。一晃就已经到了3月份，在这樱花🌸盛开的季节，终于得重新连载该系列了。在停更的期间时不时会收到大家关于DDD的留言和问题，一旦我有时间一定会回复大家的问题。在此，衷心感谢大家对本系列文章的支持😄。

概述

在实践领域驱动设计（DDD）的过程中，我们往往会遇到多个领域对象相互交互的情况。比如聚合根A在执行某操作之前需要得到聚合根B的某个信号（或某些数据）。如果在单体应用程序中，我们有条件和机会使得两者进行强引用来完成操作，但是这将直接打破领域驱动设计的规范，从而使得项目不可控，再次回到大泥球的开发。

现在，咱们可以选取一种更纯净的方式来解决这类问题，并且还能够更清晰的描述领域对象的活动迹象。这就是咱们今天的主题 ———— “领域事件”。那么到底什么是领域事件呢？引入领域事件会为我们已有的DDD项目带来哪些益处？是否一定要使用领域事件呢？ 本文将从不同的角度来带大家重新认识一下“领域事件”这个概念，并且给出相应的代码片段（本教程的代码片段都使用的是C#，当然思想是跨越任何编程语言的😀）。

什么是领域事件

在原著 《领域驱动设计:软件核心复杂性应对之道》 其实并没有直接提及到关于领域事件的介绍。领域对象是在后期才被作者Evans提出，经过Udi Dahan（Nservicebus作者）和Jimmy Bogard（MetdiaR、AutoMapper作者）等专家后期的不断实践和演变才有了今天的领域事件版本。

此处我摘录了《实现领域驱动设计》书中对领域事件的描述：

领域专家所关心的发生在领域中的一些事件。
将领域中所发生的活动建模成一系列的离散事件。每个事件都用领域对象来表示，领域事件是领域模型的组成部分，表示领域中所发生的事情。

如何使用领域事件

当您一看到“事件”这个词语的时候，您可能会一下联系到 C# 中的事件，那个基于委托的事件。 确实，它们之间有着共性，就比如：“当事件发生的时候，与该事件相关联的对象都将受到波及。” 所以，如果您了解C#中的事件，那将帮助您更好的理解“领域事件”。

由此我们可以推导出：在领域驱动设计建模过程中，如果发现有一项动作发生了之后，与之关联的其他领域对象将会受到波及。 那么该动作可能就是“领域事件”。

光从概念上来讲些许有些让人头晕，我们来看看实际的一个例子：“当用户将商品添加到购物车的时候，下方的推荐商品将为他推荐同类型的商品”。 这是一个有前后发生关系的典型案例，商品被添加到了购物车就会引发推荐同类商品。 所以咱们仔细来感受一下这一个过程，抓一抓里面的关键词。“商品加入购物车” 就会导致 “推荐同类商品”。是不是和咱们上面那一段的描述有些类似了？ 所以仔细观察之后，我们可以捕获出一个领域对象来，该对象您可能将它命名为（ProductAddedEvent）。

为什么我们要将它命名为过去时呢？ 这也是印证了开头那句话“动作发生了之后”。当该事件被捕获了之后，就会将事件信息传递给“推荐商品”聚合根，执行相应处理逻辑。

那么事件的来源是哪里呢？“用户点击”，“网页响应” 这些都不是哦！ 记住，我们要深刻关心领域对象，刚才所说的情况显然与咱们的领域对象一点儿关系也没有。所以我们可以很自然的将目光转向到“购物车”，“购物车”可能就是一个聚合根，它会有一个叫做“添加商品”的行为，当该行为完成之后就会引发一个“商品添加完成”的事件。

经过整理之后我们可能会得到一个这样的流程：

所以您会发现，领域事件一方面充当了描述领域信息的作用，一方面承接了不同聚合根之间的交互。 当然事件不一定只有一个，被影响的领域对象也不一定只有一个。就好比“推荐商品”受到了“商品添加完成”事件之后，它自己也能产生一个另外的领域事件传递给下游。

思维的转换

到这里您或许会感到使用领域事件和以往咱们捕获其他对象不太一样，比如捕获值对象、实体等。因为对于领域事件来说，它可能是“隐式”，我们没有直观的感受它的存在。

所以，请仔细的考虑这一点：当您要使用领域事件时，您将认同您的项目需要以事件作为中心。 而项目中的各个领域对象都将以产生、发布领域事件完成一系列的交互流程。

这里我摘录了《领域驱动设计模式、原理与实践》中的一段话分享给大家：“领域事件将会在领域专家一起进行的知识提炼环节中揭示出来。揭示领域事件是如此有价值，DDD实践者都拥有创新的知识提炼技术来进行实践以便让其更专注于事件，比如事件风暴。不过，使用这些创新技术会带来新的挑战。既然概念化的模型都是以事件为中心的，那么代码也需要以事件为中心，以便它能够表述概念化模型。这就是领域事件设计模式所带来的价值。”

所以在大多数时候您将感受到项目逐渐具有 EDA（事件驱动架构）的风格。而此时，您可能会联想到DDD中的另外一种模式：事件溯源（