2. 事件风暴基础：定义、角色与核心元素
事件风暴（Event Storming）是由 Alberto Brandolini 提出的一种协作建模技术，它将领域专家、开发人员、业务分析师和架构师聚集在一起，通过“事件”作为统一语言，快速探索复杂业务领域。在分布式事务与 Saga 模式的设计中，事件风暴是识别业务边界、发现补偿动作、划分限界上下文的核心工具。
2.1 事件风暴的定义与价值
事件风暴是一种基于时间线的、高度协作的工作坊式建模方法。参与者使用不同颜色的便签纸，在墙面上逐步构建出业务全景图。其核心价值在于：
- 消除认知鸿沟：业务人员与技术团队使用同一套“事件”语言沟通。
- 快速发现业务边界：通过事件流动，自然识别出聚合与限界上下文。
- 暴露分布式事务痛点：跨上下文的事件流直接揭示需要 Saga 或 TCC 等模式介入的节点。
- 降低前期设计成本：避免在未理解业务全貌前就陷入技术选型。
实践提示： 在 Saga 模式设计中，事件风暴的产出物（事件流、补偿事件、聚合边界）是后续设计 Saga 编排器、定义本地事务与补偿动作的直接输入。建议在事件风暴工作坊中专门预留一个“补偿事件”环节。
2.2 事件风暴中的角色
一场成功的事件风暴工作坊需要以下关键角色协同工作：
| 角色 | 职责 | 典型参与者 |
|---|---|---|
| 领域专家 | 提供业务知识、规则和异常场景；验证事件与命令的真实性 | 业务经理、运营主管、资深业务员 |
| 事件风暴引导师 | 控制节奏、提问启发、确保全员参与；维护时间线秩序 | 资深架构师、敏捷教练 |
| 领域建模师 | 将业务概念转化为事件、命令、聚合等模型元素 | DDD 实践者、技术负责人 |
| 开发人员 | 从实现角度提出约束、识别技术风险；记录边界与接口 | 后端开发、全栈工程师 |
| 记录员 | 实时拍照、整理便签、生成电子版画布 | 技术文档工程师、实习生 |
2.3 核心元素详解
事件风暴使用四种核心元素构建业务全景。每个元素都有固定的颜色和语义，不可混淆。
2.3.1 事件（Event）—— 橙色便签
事件是已经发生的、不可改变的事实，用过去时态描述。它是事件风暴的“第一公民”，所有建模都围绕事件展开。
- 格式：名词 + 动词过去式，例如“订单已创建”、“支付已成功”、“库存已扣减”。
- 粒度：一个事件对应一次业务状态变更，不要将多个事实合并为一个事件。
- 触发源：事件可以由用户命令、定时器、外部系统或另一个事件触发。
示例： 在电商下单流程中，事件包括：
订单已提交 → 支付已发起 → 支付已成功 → 库存已预占 → 订单已确认。其中“支付已成功”是 Saga 模式中典型的正向事件，而“支付已失败”则是触发补偿的逆向事件。
2.3.2 命令（Command）—— 蓝色便签
命令是用户或外部系统发出的意图或请求，它可能成功也可能失败。命令是事件的直接驱动力。
- 格式：动词 + 名词，例如“提交订单”、“发起支付”、“确认发货”。
- 位置：命令通常贴在对应事件的左侧，表示“这个命令导致了那个事件”。
- 权限与验证：命令在执行前需要经过权限校验和业务规则验证。
2.3.3 聚合（Aggregate）—— 黄色便签
聚合是一组具有完整业务一致性的对象集合，它有一个根实体（Aggregate Root）作为外部访问的唯一入口。聚合是事务一致性的边界。
- 事务边界：一个聚合内的所有状态变更必须在同一个本地事务中完成。
- 分布式事务映射：在 Saga 模式中，每个 Saga 步骤通常对应一个聚合的本地事务。
- 标识：聚合通过全局唯一标识符（如 UUID）引用。
常见误区： 不要将聚合设计得过大。过大的聚合会导致事务冲突频繁、性能下降。在分布式系统中，聚合的粒度直接影响 Saga 的步骤数量和补偿复杂度。一个聚合通常不超过 5~7 个实体对象。
2.3.4 限界上下文（Bounded Context）—— 大框或边界线
限界上下文是模型边界，它定义了某个领域模型适用的范围和语义。不同限界上下文之间通过上下文映射进行集成。
- 划分依据：团队组织、业务语义、数据所有权、变更频率。
- 通信方式：限界上下文之间通常通过事件或API进行异步通信，这正是 Saga 模式发挥作用的场景。
- 分布式事务边界：跨限界上下文的事务必须使用 Saga 或 TCC 等最终一致性方案，不能使用本地事务。
2.4 核心元素关系图
下图展示了事件风暴中四个核心元素之间的典型关系：
2.5 元素对比速查表
| 元素 | 便签颜色 | 时态 | 是否可撤销 | Saga 中的角色 |
|---|---|---|---|---|
| 事件 | 橙色 | 过去时 | 不可撤销（可补偿） | 正向步骤完成信号 / 补偿触发信号 |
| 命令 | 蓝色 | 现在时（意图） | 可取消（未执行前） | Saga 编排器发出的指令 |
| 聚合 | 黄色 | 无时态 | 状态可回滚 | 本地事务执行单元 / 补偿操作目标 |
| 限界上下文 | 大框/边界线 | 无时态 | 不适用 | Saga 跨服务边界 / 分布式事务分割点 |
2.6 从事件风暴到 Saga 模式的映射
事件风暴的产出物可以直接映射到 Saga 模式的设计要素：
- 正向事件流 → Saga 的正向步骤（每个事件对应一个本地事务完成信号）。
- 补偿事件（如“订单已取消”、“支付已退款”） → Saga 的补偿步骤。
- 聚合 → Saga 中每个步骤的本地事务边界。
- 限界上下文边界 → Saga 的跨服务通信点（通常使用消息队列或事件总线）。
- 命令 → Saga 编排器向参与者发出的执行指令。
映射示例： 在“订单已提交”事件发生后，Saga 编排器发出“预占库存”命令给库存上下文。库存聚合执行本地事务后发布“库存已预占”事件。如果后续“支付已失败”事件发生，编排器发出“释放库存”补偿命令，库存聚合执行回滚操作并发布“库存已释放”事件。
2.7 事件风暴工作坊的典型流程
一个标准的事件风暴工作坊通常按以下步骤进行：
| 阶段 | 活动 | 产出物 | 耗时参考 |
|---|---|---|---|
| 1. 混沌探索 | 全员自由粘贴所有能想到的事件 | 无序的事件便签墙 | 30~60 分钟 |
| 2. 时间线排序 | 按时间顺序排列事件，识别缺失事件 | 有序的事件时间线 | 20~40 分钟 |
| 3. 命令与聚合识别 | 为每个事件补充触发命令和执行聚合 | 事件-命令-聚合映射表 | 40~60 分钟 |
| 4. 限界上下文划分 | 用大框圈出属于同一上下文的聚合组 | 限界上下文边界图 | 20~30 分钟 |
| 5. 异常与补偿分析 | 识别失败场景，补充补偿事件 | 补偿事件列表（Saga 输入） | 30~45 分钟 |
避坑指南： 在“混沌探索”阶段，不要过早讨论技术实现细节（如消息队列选型、数据库事务隔离级别）。事件风暴的目的是理解业务，不是设计技术架构。技术决策应在限界上下文划分完成后，结合 Saga 模式需求进行。