Event Storming（事件风暴）：通过绘制事件图来理解和建模业务过程

Event Storming（事件风暴）是一种高效的团队协作方法，旨在通过集体讨论和可视化的方式，帮助团队快速理解和建模复杂的业务领域，从而指导软件设计。这种方法强调以事件为核心，通过识别关键事件、发现限界上下文、定义领域模型等步骤，促进团队协作，提高建模效率，确保领域模型的一致性和准确性。以下是对事件风暴的详细讲解，并结合一个实际案例进行说明。

一、事件风暴的基本概念

事件风暴由Alberto Brandolini提出，是一种灵活的工作坊（workshop）形式的活动，适用于多种不同的场景，如发掘现有业务线中的改进点、探索新业务模式的可行性、设计整洁可维护的事件驱动型软件等。其核心在于通过集体讨论和可视化手段，识别和绘制领域中的关键事件，进而发现和定义限界上下文、聚合、命令等领域驱动设计（DDD）概念。

在事件风暴中，有几个基本元素至关重要：

1. 事件（Event）：事件即事实，是在业务领域中已经发生并对系统产生了业务上影响的动作。事件通常使用正方形橘黄色的便利贴表示，并且是过去式，如“用户已注册（User Registered）”、“激活邮件已发送（Activation Email Sended）”等。
2. 决策命令（Command）：决策命令是产生事件的动作，与事件一一对应。它用正方形蓝色便利贴表示，如“注册用户（Register User）”对应“用户已注册（User Registered）”事件。
3. 参与者（Actor）：参与者是发起决策动作的对象，可以是用户、信息系统、操作系统等。在事件风暴中，需要识别出触发每个事件的参与者，并用小长方形亮黄色便利贴表示。
4. 热点（Hotspot）：热点表示不确定的点、有风险的点或者需要特别注意的点，一般贴在事件旁边，用紫色的便利贴表示。
5. 读模型（Read Model）：读模型是支撑参与者更容易做出决策命令的信息展示方式，通常通过Web页面（UI/UX）来展示。在事件风暴中，读模型用绿色正方形的即时贴表示。
6. 聚合（Aggregate）：聚合是领域模型中的一个概念，表示一组具有内聚关系并一起被管理的实体。在事件风暴中，聚合用大长方形的黄色即时贴表示。

二、事件风暴的步骤与实践形式

事件风暴通常包括以下几个步骤：

1. 确定目的和期望：组织人员明确本次活动的目的和自己的期望，并提前与主持人沟通。
2. 邀请对的人：根据目的和期望来确定要邀请的人，控制邀请的人数（6-15人左右），确保邀请的人都是与项目相关的人。
3. 预定活动场地与准备物料：提前预定会议室，场地尽可能大，并准备一面4米左右的墙壁或大白纸用于张贴便利贴。同时准备黑色马克笔、不同颜色和大小的即时贴等物料。
4. 活动开始：主持人简单介绍事件风暴，说明本次活动的目的以及业务范围。然后大家一起贴业务事件，按照时间顺序从头开始整理所有业务事件，并将热点识别并贴出来。
5. 从第一个事件开始识别并添加参与者（Actor）：识别出触发每个事件的参与者，并用亮黄色便利贴表示。
6. 划分上下文与添加决策命令：通过事件之间的关系，发现和定义限界上下文，并用绿色便利贴表示。同时，识别触发每个事件的决策命令，并用蓝色便利贴表示。
7. 增加读模型和UI设计草图：根据参与者做出决策的需要，设计读模型和UI草图，并用绿色和黄色长方形即时贴表示。
8. 整理与输出：将讨论结果整理成文档，包括事件、命令、聚合、限界上下文等，并拍照记录整个白板或墙上的内容以便后续参考。

事件风暴有两种主要的实践形式：

1. Big-Picture Event Storming：一种进行业务全景探索的事件风暴形式。通常由产品经理或开发Leader/架构师作为主持人，邀请市场分析员、业务人员、财务、UX等部门的代表参与。目的是与所有的利益相关人一起探索发现业务全景，搭建一个平台让Stakeholder能贡献自己的专业知识，让所有人知道全景/边界、风险点、在此项目中的职责并发现产品/项目的逻辑漏洞。
2. Design-Level Event Storming：一种用于更细节的软件设计的事件风暴形式。由开发Leader/架构师作为主持人，邀请业务人员/产品经理、研发团队（包括测试、前端/后端、UI等）的所有其他人员参与。目的是让研发团队所有人都知道某个上下文的业务全景，学习更多的业务知识，以便开始研发工作；同时进行业务建模、统一业务语言以及确定业务优先级。

三、事件风暴的案例讲解

假设我们正在设计一个电子商务平台，需要通过事件风暴来建模订单管理、库存管理和用户管理等子系统。以下是具体步骤：

1. 准备材料：便签纸（橙色、蓝色、黄色、绿色、紫色、粉色）、标记笔、大白板或墙、计时器。
2. 识别关键事件：团队成员讨论并识别出以下关键事件，并用橙色便签记录：订单创建（Order Created）、订单支付（Order Paid）、订单发货（Order Shipped）、库存减少（Stock Decreased）。将这些事件按照时间顺序张贴在白板上。
3. 发现命令和聚合：识别触发每个事件的命令，如创建订单（Create Order）→订单创建（Order Created），并用蓝色便签记录贴在相应事件的上方。同时识别每个事件和命令所涉及的聚合，如订单（Order）→订单创建、订单支付、订单发货，库存（Stock）→库存减少，并用黄色便签记录贴在相应事件和命令的旁边。
4. 发现限界上下文：通过事件、命令和聚合之间的关系，识别出以下限界上下文：订单管理上下文（Order Management Context）、库存管理上下文（Inventory Management Context）、用户管理上下文（User Management Context）。将这些限界上下文用绿色便签记录并围在相关事件、命令和聚合的周围。
5. 识别外部系统和用户：识别与领域模型交互的外部系统，如支付系统（Payment System）与订单支付事件交互，物流系统（Logistics System）与订单发货事件交互。将这些外部系统用紫色便签记录并贴在相应的位置。同时识别与领域模型交互的用户，如客户（Customer）与订单创建、订单支付、用户注册等事件交互。将这些用户用粉色便签记录并贴在相应的位置。
6. 拍照记录与整理文档：拍照记录整个白板的内容以便后续参考，并将讨论结果整理成文档，包括事件、命令、聚合、限界上下文等。

通过上述步骤，我们成功地使用事件风暴方法建模了电子商务平台的订单管理、库存管理和用户管理等子系统。这种方法不仅帮助我们快速理解了复杂的业务领域，还促进了团队成员之间的沟通和协作，确保了领域模型的一致性和准确性。

四、事件风暴的优势与注意事项

事件风暴的优势在于：

1. 高效性：通过集体讨论和可视化手段，快速识别和建模复杂的业务领域。
2. 促进协作：促进团队成员之间的沟通和协作，确保每个人都对领域模型有一致的理解。
3. 发现隐性知识：通过集体讨论，可以发现和记录团队成员的隐性知识，避免知识孤岛。
4. 灵活性：事件风暴是一种灵活的方法，可以根据团队的实际情况进行调整和优化。

然而，在实施事件风暴时也需要注意以下几点：

1. 明确目的与期望：在活动开始前要明确本次事件风暴的目的和期望，确保所有参与者都有共同的目标。
2. 控制人数与场地：控制邀请的人数，确保场地足够大且便于张贴便利贴。
3. 准备充分：提前准备好所需的物料和资料，确保活动顺利进行。
4. 引导讨论：主持人要引导讨论，确保讨论始终聚焦在事件上，并及时识别和处理热点。
5. 整理与输出：活动结束后要及时整理讨论结果并输出文档，以便后续参考和实施。

综上所述，Event Storming（事件风暴）是一种高效的团队协作方法，通过绘制事件图来理解和建模业务过程，从而指导软件设计。它强调以事件为核心，通过集体讨论和可视化手段促进团队协作和提高建模效率。在实际应用中，我们需要根据项目的具体情况选择合适的事件风暴实践形式并遵循相应的步骤和注意事项以确保活动的成功实施。

扫描下方二维码，一个老毕登免费为你解答更多软件开发疑问！