2. 事件风暴基础：定义、角色与四步法

事件风暴（Event Storming）是由 Alberto Brandolini 提出的一种协作建模技术，通过高密度、低仪式感的“工作坊”形式，让领域专家、开发人员、业务分析师和架构师在短时间内对齐业务全景。在分布式事务场景中，事件风暴是识别业务边界、发现聚合、定义一致性边界的关键前置活动。

2.1 事件风暴的定义

事件风暴是一种基于“领域事件”的协作建模方法，参与者通过识别业务过程中发生的“事件”来逐步发现命令、聚合和限界上下文。其核心产出物包括：

2.2 事件风暴中的角色

一场成功的事件风暴工作坊需要以下角色参与，每个角色带来不同的视角：

• 领域专家（Domain Expert） — 业务规则的最终权威，回答“为什么这样做”和“什么情况下会出错”。
• 技术专家（Technical Expert） — 架构师、资深开发，负责评估技术可行性、识别分布式事务风险。
• 引导师（Facilitator） — 控制节奏、提问、记录，确保讨论不偏离时间线。
• 记录员（Scribe） — 将便签内容数字化，维护最终画布。
• 决策者（Decision Maker） — 产品经理或业务负责人，在边界争议时做最终裁决。

2.3 事件风暴四步法

四步法是事件风暴的标准流程，从混沌到有序，逐步收敛出可落地的模型。每一步对应一种颜色的便签：

步骤一：混沌（Chaos）

参与者自由地在时间线上贴出所有能想到的“领域事件”，不讨论对错、不排序、不质疑。目标是让隐性知识充分暴露。引导师在此阶段只做记录，不打断。

步骤二：命令（Command）

为每个事件贴上触发它的“命令”，并标注执行命令的“角色”。命令是用户或系统发出的指令，格式为“动词+宾语”，例如“提交订单”、“审批退款”。

步骤三：事件（Event）

重新审视事件，补充缺失的事件、删除重复事件、调整时间顺序。此时要关注事件的“因果链”：一个事件的发生是否导致另一个命令的触发？

步骤四：聚合（Aggregate）

将高内聚的命令、事件和数据归为一组，形成聚合。聚合是分布式事务的最小原子单元——一个事务只能修改一个聚合，跨聚合修改必须通过最终一致性。

2.4 四步法流程示意图

下图展示了四步法的演进关系，从无序的事件流逐步收敛为带有聚合边界的结构化模型：

2.5 四步法在分布式事务中的实践映射

将四步法的产出物映射到分布式事务设计，可以得到清晰的对应关系：

2.6 四步法常见避坑指南

• 混沌阶段过度讨论 — 不要在一个事件上停留超过 2 分钟，先贴出来，后面再精化。
• 命令与事件混淆 — 命令是“做某事”，事件是“某事已发生”。命令用蓝色便签，事件用橙色便签，严格区分。
• 聚合粒度失控 — 如果一个聚合包含超过 7 个命令，通常意味着边界过大，需要拆分。
• 忽略角色权限 — 每个命令必须标注执行角色，这是后续 OAuth2.0 权限设计的基础输入。