03｜事件风暴（上）：怎样和业务愉快地聊需求？

问题与挑战

1）领域专家很可能不会像我们上一讲那样，一开始就把需求都一一列出来，需求可能仅仅停留在领域专家的脑子里。所以，我们就需要一种方法，能够将这些头脑中的需求挖掘出来。 2）即便领域专家已经把需求写出来，我们也很难保证没有遗漏，保证开发人员都彻底理解了

事件风暴解决的问题 1）不仅能帮助我们把需求补充完全，而且还能以协作的方式保证业务人员和技术人员对需求理解一致。 2）帮助我们识别领域对象，这也是我们进行领域建模前的重要一步。

为了理解需求，我们首先要分析系统具有哪些功能，这些功能由什么人操作，会产生什么效果。这个过程传统上叫做“捕获行为需求”。

捕获行为需求的方法有好几种，在传统的软件工程中，最常用的方法是“用例”，也就是 Use Case。

Eric Evans 在《领域驱动设计》这本书里，并没有规定捕获行为需求的具体方法。直到 2013 年，一位叫 Alberto 的 DDD 专家提出了“事件风暴”，也就是 Event Storming。这种方法简单易学，而且充分体现了 DDD 中沟通协作、统一语言等要点，所以逐渐开始流行起来。

事件风暴的主要过程: 1)找出业务流程中发生了哪些事件 2）识别用户角色，谁做了什么操作导致事件发生 3）识别领域名词，即实体，为领域建模打基础

人员准备：业务人员和技术人员协作完成；业务人员通常是领域专家，包括产品经理、PO、BA. 技术人员通常是架构师、开发人员、测试人员；

场地准备：大会议室器材准备：白板、便利贴。

业务人员讲一遍需求，然后开始识别领域事件。所谓领域事件，就是业务过程中已经发生的事。比如订单已提交、商品已签收。实际上，领域事件是业务过程发生的结果。（事件风暴的作者认为，从结果梳理需求，比从操作入手，更容易把业务想清楚）

事件的命名规范：完成时+被动语态。

把业务流程中的领域事件，按时间顺序排列。通过充分讨论，统一语言且尽量使用通用术语，并且把领域事件补充完整，统一后如下：

完整的领域事件如下

1）不要把技术事件当领域事件，比如数据库事务已回滚 2）查询功能不算领域事件，领域事件应该是对某样事务产生的影响，并被记录。是某个事件的增、删、改操作。通知事件也是领域事件。查询功能要以另外的方式呈现。

掌握事件风暴的概念和具体操作：在识别领域事件过程中，不断地讨论、澄清误解、补充遗漏、发现业务规则。事件风暴即头脑风暴，充分讨论。讨论过程中，使用统一语言，是DDD的核心模式，减少沟通成本。

事件风暴可分为两大过程： 1）识别领域事件，发散过程 2）统一语言，收敛过程协作是事件风暴的精髓。

1）事件风暴是中间产物，最终输出物：用户旅程地图、服务蓝图、UML领域模型。 2）如果事件本身很简单，但是业务规则非常复杂，这种情况怎么去揭示复杂的业务规则呢？使用业务规则表