对于大多数人来讲，在实际业务系统设计与开发的工作中，最难的一步并不是如何获得模型，而是与业务方共创，最后说服并接受模型。有没有一种好的方法可以在讨论的过程中，更自然地完成模型共创，并最终对模型达成一致呢？那就是事件风暴法。

事件风暴法，它是目前最为流行的事件建模法。事件风暴是Alberto Brandolini在2012年创造的一种事件建模法。在形式上，事件风暴是一种互动式的建模工作坊，通过把不同背景的项目参与方汇聚一堂，集思广益，从而形成有效的模型。这也正是事件风暴名称的由来。它本质上是一种头脑风暴，按照欧美人士这种习惯的俏皮式的命名法，把头脑改成它建模法的关键元素，事件由此得名。

事件风暴的核心思想是通过集体智慧和协作来快速创建一个可行的业务模型。它强调所有参与者平等地分享他们的知识、经验和观点，以便快速建立一个共同理解和共识，并且鼓励参与者在短时间内快速原型设计和迭代，以达到最终的目标。它是一种快速而灵活的方法，适用于业务建模、需求分析、产品设计等多种场景。

事件风暴法，本质上它是一种事件建模法。它把响应式编程作为一个默认的范式，通过事件命令和策略之间的响应关系，来组织逻辑。

这张图，展示了事件风暴的主要概念和它相互之间的关联。以下是几个关键概念：

关键概念

1. Actors（使用者）：表示系统的使用者。这里的使用者是一个相对模糊的概念，可能是现实中的人，也可能是别的系统。
2. Event（事件）：表示一个已经发生的事情或者状态变化，一般包含事件名称、事件源、事件发生的时间点以及一些事件相关的信息。
3. Command（命令）：表示一个请求或者要求系统做出某种操作的指令，一般包含命令名称、命令的参数以及相关的约束条件。
4. System（系统）：表示整个软件系统，是由多个聚合、策略、命令和事件组成的。
5. Read Model（读模型）：是系统中用于读取和显示数据的模型，通常使用一些查询来构建。Read Model 是根据 Command 和 Event 产生的，用于反映系统的状态。
6. Policy（策略）：表示一些业务规则，通常用于指导系统的行为和响应。Policy 可以根据 Command 和 Event 来产生，并且可以修改聚合的状态。
7. Aggregate（聚合）：是事件风暴中一个重要的概念，用于描述一组相关的对象或实体。聚合通常是由一个或多个对象组成的，这些对象共享一个相同的生命周期，并且有一个聚合根来协调它们之间的关系。

在事件风暴中，通过对这些概念的定义和组合，可以对业务问题进行建模和分析，帮助开发团队更好地理解业务需求，并有效地设计和实现系统功能。

整体流程

事件风暴推荐使用七种不同的颜色来表示七种不同的一个概念。下面我们来看一看这个事件风暴建模的整体流程，大致分为五个阶段。

1. 通过头脑风暴我们来寻找领域事件；
2. 根据领域事件寻找触发它的命令和行动者；
3. 通过事件寻找策略以及由策略发动的SIC；
4. 根据命令与事件寻找产生了变化的聚合以及新生成的阅读模型；
5. 根据寻找到的聚合、阅读模型、事件，开始扩大、细化领域模型。

再细化，整体建模流程也可以遵循如下：

1. 确定问题：首先，需要确定需要解决的问题，以及问题的背景和目标。
2. 确定参与者：接下来，需要确定所有参与者，包括用户、系统和外部系统。
3. 制定事件清单：然后，需要制定一份事件清单，包括所有的事件和命令，并标注出它们之间的关系。
4. 识别领域模型：基于事件清单，可以识别出领域模型，并绘制出其模型图。
5. 确定策略和规则：接下来，需要确定所有策略和规则，以及它们的优先级和关系。
6. 定义命令和查询：在此基础上，可以定义所有命令和查询，并绘制出其模型图。
7. 确定聚合根：然后，需要确定所有聚合根，并将其绘制出来。
8. 绘制完整模型：最后，将所有的模型组合在一起，绘制出完整的系统模型。

以上是事件风暴的整体建模流程，遵循了事件建模的大体框架，它的特点就在于，通过头脑风暴发现事件，再依赖触发和响应寻找事件的关系，通过聚合和阅读模型寻找领域模型，可以帮助团队更快速、更有效地设计出复杂的业务流程或系统。

接下来，我们还是拿视频网站VIP视频来举例，展示一下事件风暴建模法的大致的过程。我们的场景是这样的，用户发现了想看的内容，但是因为没有会员就看不了，于是下单了购买了会员。完成支付之后，再次访问之前的内容，就可以看了。

首先我们从事件入手，根据上面的流程，我们其实可以很容易的通过头脑风暴得到领域事件，也就是内容请求、拒绝访问、订单确认、订单支付、内容被访问这样的几个事情。这里面，我们其实可以很容易发现一个规律，这个事件都是以名词加动词被动式来表达的。在寻找到我们这些事件之后，我们需要判断有哪些是用户驱动，有哪些是就是系统驱动的。要知道用户驱动是由命令触发的，而系统是由策略触发的。

Event: 用户购买VIP会员

事件是指业务中发生的一些重要的状态变化，这里的事件是用户购买VIP会员，可以表示为”UserBuyVIPEvent”。事件的数据包括用户ID，购买日期，VIP会员类型等。

Command: 开通VIP服务

Command是指用户发起的请求，这里的Command是”UserOpenVIPCommand”，可以由用户通过点击按钮发起请求，命令的数据包括用户ID、VIP会员类型等。

System: 开通VIP服务

System是指具体实现Command的执行者，这里可以将System表示为”VIPSystem”，负责开通VIP服务，操作的数据包括用户ID、VIP会员类型等。

Read Model: VIP会员信息

Read Model是指展示给用户的数据模型，这里的Read Model是”VIPMemberInfo”，包括用户ID、VIP会员类型、过期时间等。

Policy: VIP会员过期策略

Policy是指业务规则，这里的Policy是”VIPExpirationPolicy”，决定VIP会员的过期时间，可以根据不同的VIP会员类型设置不同的过期时间。

Aggregate: 用户

Aggregate是指业务中的核心实体，这里的Aggregate是”User”，包括用户ID、用户名、密码、VIP会员状态等。

以上是事件风暴建模的一个简单示例。

此外，写入数据与查询数据一定要用同一个模型吗？在原味面向对象模型中，答案是一样的。而越来越多的实践者发现，分开可能更好，毕竟两者对于逻辑一致性的诉求是不同的，分开处理能得到更好的结果。于是在事件风暴建模法中，阅读模型是包含写入与查询所有数据形态的总和，而聚合只是阅读模型中符合对象风格的一些子集。所以，当我们找到一些阅读模型后，再回过头来去看之前留白不易处理的部分，就豁然开朗了。

内容访问策略所需要使用的订阅读模型，决定了哪些内容对哪些用户。可见，在获取了聚合和阅读模型之后，我们就可以开始细化领域模型了。这时候的方法和原味对象方法就没什么不同了，我就不再赘述了。

通过这个简单的例子，相信你对事件风暴法的基本流程已经有所了解了。通过头脑风暴发现领域事件，以对事件的响应为主要的维度，去寻找事件间的关联。通过阅读模型和聚集发现事件与领模型之间的关系，可以发现事件风暴法是一种简单明快的事件解模法，可以更清晰地理解业务中各个部分的关系，为业务开发提供指导意义。