3. 事件风暴（Event Storming）入门
事件风暴是由 Alberto Brandolini 于 2013 年提出的一种协作式、基于黏性便签的领域建模工作坊技术。它通过将业务专家、开发人员、产品经理等角色聚集在同一面“墙”前，以领域事件为时间轴，快速探索业务全貌、发现核心问题域，并最终产出领域模型与限界上下文。本章将系统介绍事件风暴的起源、四种核心元素以及标准工作坊流程，为后续在订单系统中实战应用打下坚实基础。
3.1 事件风暴的起源
事件风暴诞生于 DDD（领域驱动设计）社区对传统建模方法的反思。Brandolini 发现，传统的 UML 建模会议往往由架构师主导，业务专家被动参与，导致模型严重偏离真实业务。他提出了一种“反会议”式的建模方式：
- 时间轴驱动：以“过去发生了什么 → 现在发生了什么 → 未来会发生什么”为线索，而非以系统功能或数据库表结构为线索。
- 大规模协作：一次工作坊通常邀请 10–30 人，包括业务专家、领域专家、开发、测试、运维、产品经理等。
- 低门槛工具：仅需一面足够大的墙、大量不同颜色的黏性便签和马克笔，无需任何建模工具或 IDE。
- 快速迭代：一次工作坊通常持续 2–4 小时，即可产出可落地的领域模型草图。
事件风暴最初在意大利的金融科技公司被验证，随后在 DDD 社区迅速传播，成为目前最流行的领域建模实践之一。它特别适合复杂业务系统的初始建模、遗留系统重构、以及微服务拆分场景。
3.2 四种核心元素
事件风暴使用四种不同颜色的便签来代表四种核心建模元素。每种元素都有严格的语义和放置规则。下表总结了它们的定义、颜色约定和示例：
| 元素 | 便签颜色 | 定义 | 订单系统示例 |
|---|---|---|---|
| Domain Event （领域事件） |
橙色 | 业务中已经发生的、不可改变的事实。通常使用过去时态命名。 | 订单已创建、支付已成功、库存已扣减、物流已发货 |
| Command （命令） |
蓝色 | 触发领域事件的用户意图或系统指令。通常使用祈使句命名。 | 创建订单、提交支付、确认发货、取消订单 |
| Aggregate （聚合） |
黄色 | 一组具有事务一致性的领域对象集合，是命令的执行者和事件的产生者。 | 订单聚合（Order）、支付聚合（Payment）、库存聚合（Inventory） |
| Policy （策略/规则） |
紫色 | 当某个领域事件发生后，自动触发的业务规则或流程。通常表现为“当……时，执行……”。 | 当支付成功时，自动扣减库存；当订单超时未支付时，自动取消订单 |
四种元素之间的关系可以概括为：用户或系统发出 Command → 由 Aggregate 处理 → 产生一个或多个 Domain Event → 某些 Domain Event 会触发 Policy → Policy 可能发出新的 Command。这个循环构成了事件风暴建模的基本单元。
3.3 四种核心元素关系图
下图展示了 Command、Aggregate、Domain Event 和 Policy 之间的典型协作关系。这是事件风暴建模中最核心的“事件循环”模式。
3.4 工作坊流程
一次标准的事件风暴工作坊通常包含以下 5 个阶段。每个阶段都有明确的目标、产出物和参与者角色。
阶段 1：混沌探索（Chaotic Exploration）
- 目标：在不受约束的情况下，尽可能多地收集领域事件。
- 活动：所有参与者使用橙色便签，在墙上贴出他们认为业务中发生的所有事件。不讨论、不质疑、不排序。
- 产出：一面贴满橙色便签的“事件墙”，通常包含 50–200 个领域事件。
- 时间：30–45 分钟。
阶段 2：时间线排序（Timeline Ordering）
- 目标：将混沌的事件按时间顺序排列，形成业务的时间轴。
- 活动：团队一起将橙色便签从左到右（或从上到下）按发生的时间顺序排列。发现缺失的事件时，随时补充。
- 产出：一条清晰的事件时间线，通常以“开始”和“结束”事件为边界。
- 时间：20–30 分钟。
阶段 3：命令与聚合识别（Command & Aggregate Identification）
- 目标：为每个领域事件找到触发它的命令，以及执行该命令的聚合。
- 活动：在每个橙色事件左侧贴上蓝色便签（Command），在蓝色便签下方贴上黄色便签（Aggregate）。
- 产出：事件、命令、聚合三者对齐的“三明治”结构。
- 时间：30–45 分钟。
阶段 4：策略与规则发现（Policy Discovery）
- 目标：识别事件之间的自动触发规则。
- 活动：在需要自动触发的事件之间贴上紫色便签（Policy），并用箭头连接。例如：事件 A → Policy → 命令 B。
- 产出：完整的“事件 → 策略 → 命令”链路。
- 时间：20–30 分钟。
阶段 5：限界上下文划分（Bounded Context Partitioning）
- 目标：根据聚合的归属和业务语义，将整个模型划分为多个限界上下文。
- 活动：使用粗马克笔或胶带，在墙上画出边界线，将相关的聚合和事件圈在一起。为每个上下文命名。
- 产出：限界上下文地图，每个上下文包含一组聚合、事件和策略。
- 时间：20–30 分钟。
- 先发散，后收敛：阶段 1 和 2 鼓励发散，阶段 3–5 逐步收敛。
- 尊重便签颜色：不要混用颜色，每种颜色有严格的语义。
- 允许“我不知道”：遇到不确定的事件或命令时，贴上问号便签，后续由领域专家补充。
- 拍照存档：工作坊结束后，对整面墙进行高清拍照，作为后续建模的原始素材。
3.5 工作坊流程总览图
下图将上述 5 个阶段整合为一个完整的流程视图，展示了从混沌探索到限界上下文划分的演进路径。
3.6 本章小结
- 事件风暴是一种协作式领域建模技术，起源于 DDD 社区，强调“对话”而非“文档”。
- 四种核心元素：Domain Event（橙色）、Command（蓝色）、Aggregate（黄色）、Policy（紫色），它们构成了事件风暴建模的基本语法。
- 工作坊流程包含 5 个阶段：混沌探索 → 时间线排序 → 命令与聚合识别 → 策略与规则发现 → 限界上下文划分。
- 事件风暴的最终产出是限界上下文地图，它直接指导微服务拆分和聚合设计。