DDD将研发者的目光首先聚焦在业务本身上，使技术架构和代码实现成为软件建模过程中的“副产品”。事件风暴都能有效地实现领域驱动设计，从而建立起良好的领域模型及服务边界。

一、领域事件

想一下计算机硬件的工作原理，整个计算机的工作过程其实就是一个对事件的处理过程。当你点击鼠标、敲击键盘或者插上U盘时，计算机便以中断的形式处理各种外部事件。在软件开发领域，事件驱动架构（Event Driven Architecture，EDA）早已被开发者用于各种实践，典型的应用场景比如浏览器对用户输入的处理、消息机制以及SOA。

1.1 什么是领域事件

领域事件（Domain Events）是领域驱动设计（Domain Driven Design，DDD）中的一个概念，用于捕获我们所建模的领域中所发生过的事情。领域事件本身也作为通用语言（Ubiquitous Language）的一部分成为包括领域专家在内的所有项目成员的交流用语。比如，在用户注册过程中，我们可能会说“当用户注册成功之后，发送一封欢迎邮件给客户。”，此时的“用户已经注册”便是一个领域事件。

当然，并不是所有发生过的事情都可以成为领域事件。一个领域事件必须对业务有价值，有助于形成完整的业务闭环，也即一个领域事件将导致进一步的业务操作。举个咖啡厅建模的例子，当客户来到前台时将产生“客户已到达”的事件，如果你关注的是客户接待，比如需要为客户预留位置等，那么此时的“客户已到达”便是一个典型的领域事件，因为它将用于触发下一步——“预留位置”操作；但是如果你建模的是咖啡结账系统，那么此时的“客户已到达”便没有多大存在的必要——你不可能在用户到达时就立即向客户要钱对吧，而”客户已下单“才是对结账系统有用的事件。

1.2 领域事件的应用

在DDD中有一条原则：一个业务用例对应一个事务，一个事务对应一个聚合根，也即在一次事务中，只能对一个聚合根进行操作。但是在实际应用中，我们经常发现一个用例需要修改多个聚合根的情况，并且不同的聚合根还处于不同的限界上下文中。比如，当你在电商网站上买了东西之后，你的积分会相应增加。这里的购买行为可能被建模为一个订单（Order）对象，而积分可以建模成账户（Account）对象的某个属性，订单和账户均为聚合根，并且分别属于订单系统和账户系统。显然，我们需要在订单和积分之间维护数据一致性，通常的做法是在同一个事务中同时更新两者，但是这会存在以下问题：1）违背DDD中"单个事务修改单个聚合根"的设计原则；2）需要在不同的系统之间采用重量级的分布式事务（Distributed Transactioin，也叫XA事务或者全局事务）；3）在不同系统之间产生强耦合。

通过引入领域事件，我们可以很好地解决上述问题。 总的来说，领域事件给我们带来以下好处：1）解耦微服务（限界上下文）；2）帮助我们深入理解领域模型；3）提供审计和报告的数据来源；4）迈向事件溯源（Event Sourcing）和CQRS等。

还是以上面的电商网站为例，当用户下单之后，订单系统将发出一个“用户已下单”的领域事件，并发布到消息系统中，此时下单便完成了。账户系统订阅了消息系统中的“用户已下单”事件，当事件到达时进行处理，提取事件中的订单信息，再调用自身的积分引擎（也有可能是另一个微服务）计算积分，最后更新用户积分。可以看到，此时的订单系统在发送了事件之后，整个用例操作便结束了，根本不用关心是谁收到了事件或者对事件做了什么处理。事件的消费方可以是账户系统，也可以是任何一个对事件感兴趣的第三方，比如物流系统。由此，各个微服务之间的耦合关系便解开了。值得注意的一点是，此时各个微服务之间不再是强一致性，而是基于事件的最终一致性。

此外，领域事件也可以用于微服务内部，此时不需要消息中间件，可以是一个同步过程，如下

二、事件风暴

事件风暴是一项团队活动，旨在通过领域事件识别出聚合根，进而划分微服务的限界上下文。在活动中，团队先通过头脑风暴的形式罗列出领域中所有的领域事件，整合之后形成最终的领域事件集合，然后对于每一个事件，标注出导致该事件的命令（Command），再然后为每个事件标注出命令发起方的角色，命令可以是用户发起，也可以是第三方系统调用或者是定时器触发等。最后对事件进行分类整理出聚合根以及限界上下文。

2.1 创建领域事件

领域事件应该回答“什么人什么时候做了什么事情”这样的问题，在实际编码中，可以考虑采用层超类型(Layer Supertype)来包含事件的某些共有属性：

可以看到，领域事件还包含了ID，但是该ID并不是实体（Entity）层面的ID概念，而是主要用于事件追溯和日志。另外，由于领域事件描述的是过去发生的事情，我们应该将领域事件建模成不可变的（Immutable）。从DDD概念上讲，领域事件更像一种特殊的值对象（Value Object）。对于上文中提到的咖啡厅例子，创建“客户已到达”事件如下：

在这个CustomerArrivedEvent事件中，除了继承自Event的属性外，还自定义了一个与该事件密切关联的业务属性——客户人数（customerNumber）——这样后续操作便可预留相应数目的座位了。另外，我们将所有属性以及CustomerArrivedEvent本身都声明成了final，并且不向外暴露任何可能修改这些属性的方法，这样便保证了事件的不变性。

2.2 发布领域事件

推荐的方式是在聚合根中在聚合根中临时保存领域事件：

然后在资源库repository发布事件并清空聚合根中的事件。

2.3 聚合更新与事件发布的原子性

业务操作和事件发布之间应该是原子的，要么全部成功，要么全部失败以“订单积分”为例，如果客户下单成功，但是事件发送失败，下游的账户系统便拿不到事件，导致最终客户的积分并不增加。

要保证业务操作和事件发布之间的原子性，最直接的方法便是采用XA事务，比如Java中的JTA，这种方式由于其重量级并不被人们所看好。但是，对于一些对性能要求不那么高的系统，这种方式未尝不是一个选择。一些开发框架已经能够支持独立于应用服务器的XA事务管理器（如Atomikos和Bitronix），比如Spring Boot作为一个微服务框架便提供了对Atomikos和Bitronix的支持。

另一个选项是采用事件表的方式。这种方式首先将事件保存到聚合根所在的数据库中，由于事件表和聚合根表同属一个数据库，整个过程只需要一个本地事务就能完成。然后，在一个单独的后台任务中读取事件表中未发布的事件，再将事件发布到消息中间件中。

这种方式需要注意两个问题：

1）事件发布后需要在数据库标记成“已发布”状态，发布事件和标记“已发布”之间需要原子性。建议把事件的消费方创建成幂等的，即消费方可以多次消费同一个事件而不污染系统数据。这个过程大致为：整个过程中事件发送和数据库更新采用各自的事务管理，此时有可能发生的情况是事件发送成功而数据库更新失败，这样在下一次事件发布操作中，由于先前发布过的事件在数据库中依然是“未发布”状态，该事件将被重新发布到消息系统中，导致事件重复，但由于事件的消费方是幂等的，因此事件重复不会存在问题。

2）持久化机制的选择。其实对于DDD中的聚合根来说，NoSQL是相比于关系型数据库更合适的选择，比如用MongoDB的Document保存聚合根便是种很自然的方式。但是多数NoSQL是不支持ACID的，也就是说不能保证聚合更新和事件发布之间的原子性。还好，关系型数据库也在向NoSQL方向发展，比如新版本的MySQL（版本5.7）已经能够提供具备NoSQL特征的JSON存储和基于JSON的查询。此时，我们可以考虑将聚合根序列化成JSON格式的数据进行保存，从而避免了使用重量级的ORM工具，又可以在多个数据之间保证ACID，何乐而不为？

三、事件风暴工作坊

3.1 识别领域事件

3.2 识别决策命令