3. 事件风暴基础：起源、角色、准备与基本流程
事件风暴（Event Storming）是由 Alberto Brandolini 于 2013 年提出的一种协作式建模方法。它通过高密度、高互动的工作坊形式，将领域专家、开发人员、产品经理和架构师聚集在同一张“画布”前，快速发现业务核心流程、识别领域事件、界定系统边界。在分布式事务与事件驱动架构的落地过程中，事件风暴是连接业务需求与技术实现的“翻译器”。
3.1 事件风暴的起源
Alberto Brandolini 在多年的 DDD 咨询实践中发现，传统的 UML 建模和文档驱动方式存在三大痛点：
- 信息失真：业务知识经过多次转述后，关键细节丢失。
- 参与门槛高：领域专家难以理解技术建模符号，技术人员难以理解业务术语。
- 反馈周期长：模型交付后才发现理解偏差，返工成本极高。
事件风暴的核心理念是：让业务人员用自己熟悉的语言（事件、命令、角色）直接参与建模。通过即时贴（Post-it）和大幅画布，所有参与者可以同时表达、讨论、修正，在数小时内完成传统方法数周才能完成的领域探索。
3.2 事件风暴中的核心角色
一次成功的事件风暴工作坊需要以下角色协同工作。每个角色都有明确的职责和参与方式。
| 角色 | 职责 | 参与方式 |
|---|---|---|
| 领域专家 | 提供业务知识、规则、异常场景和术语定义 | 全程参与，主导事件和命令的产出 |
| 技术团队 | 评估技术可行性、识别集成点、设计聚合边界 | 观察、提问、记录技术约束 |
| 引导师 | 控制节奏、保持焦点、解决冲突、确保产出 | 中立角色，不参与业务讨论 |
| 产品经理 | 确认业务价值、优先级和用户故事 | 提供上下文，但不主导技术决策 |
| 记录员 | 拍照、整理即时贴、维护数字副本 | 不参与讨论，专注记录 |
3.3 准备工作清单
事件风暴的产出质量高度依赖准备工作。以下清单确保工作坊能够高效进行：
- 物理空间：至少一面 3m × 2m 的白板墙或可粘贴画布，确保所有参与者能同时看到全部内容。
- 物料准备：不同颜色的即时贴（建议 76mm × 76mm 以上）、粗头马克笔（黑色、蓝色、红色）、胶带、相机或手机。
- 参与者邀请：确保核心领域专家全程参与，技术团队不超过总人数的 40%。
- 范围界定：提前与产品经理确认本次探索的业务流程边界（例如：仅限“订单创建”到“订单发货”）。
- 时间预算：单次工作坊建议 3-4 小时，中间安排 15 分钟休息。超过 4 小时需要分两天进行。
- 数字工具备选：远程场景下可使用 Miro、Mural 或 Lucidchart 的“事件风暴模板”，但效率通常低于线下。
3.4 基本流程：时间线、命令、事件与聚合
事件风暴的基本流程遵循“从左到右、从粗到细”的演进逻辑。以下 SVG 展示了核心元素在画布上的布局关系：
3.4.1 时间线（Timeline）
时间线是画布的水平主轴，通常从左到右表示业务过程的先后顺序。所有事件、命令和聚合都按照时间线排列。时间线不要求严格精确到秒，只需保持相对顺序即可。例如：“订单已提交”一定在“订单已支付”之前。
3.4.2 命令（Command）
命令是用户或外部系统发出的意图，用橙色即时贴表示。命令的命名格式为“动词 + 宾语”，例如“提交订单”、“取消订单”、“修改地址”。命令是事件的直接原因，但命令本身不保证成功——它可能被拒绝或失败。
3.4.3 事件（Event）
事件是已经发生的、不可改变的事实，用蓝色即时贴表示。事件的命名格式为“名词 + 已 + 动词过去式”，例如“订单已提交”、“支付已成功”、“库存已扣减”。事件是领域专家最容易产出的元素，也是事件风暴的起点。
在分布式事务场景中，事件是最终一致性的核心载体。每个事件都应该包含足够的信息让消费者独立处理，而不需要回查源系统。
3.4.4 聚合（Aggregate）
聚合是领域驱动设计中的一致性边界，用绿色即时贴表示。聚合封装了一组业务对象，确保它们的状态变更满足业务规则。在事件风暴中，聚合通常出现在事件之后，表示“这个事件改变了哪个聚合的状态”。
聚合的识别原则：
- 一致性边界：一个事务内只能修改一个聚合实例。
- 聚合根：每个聚合有一个根实体，外部只能通过根访问聚合内部。
- 大小适中：聚合不应过大（避免性能问题），也不应过小（失去封装意义）。
3.5 事件风暴的典型流程步骤
以下步骤是标准事件风暴工作坊的执行顺序：
| 步骤 | 活动 | 产出物 | 耗时（分钟） |
|---|---|---|---|
| 1 | 混沌探索：所有参与者自由粘贴事件，不讨论、不排序 | 50-100 个无序事件 | 20-30 |
| 2 | 时间线排序：引导师带领大家将事件按时间线排列 | 有序事件流 | 15-20 |
| 3 | 命令识别：为每个事件找出触发它的命令 | 命令-事件对 | 15-20 |
| 4 | 聚合发现：识别事件所属的聚合边界 | 聚合分组 | 20-30 |
| 5 | 外部系统标注：标记与聚合交互的外部系统 | 系统上下文图 | 10-15 |
| 6 | 验证与调整：走读整个流程，修正遗漏或错误 | 最终画布 | 20-30 |
以下 SVG 展示了从混沌探索到聚合识别的完整流程：
3.6 事件风暴与分布式事务的关联
在分布式事务场景中，事件风暴产出的“事件”和“聚合”直接对应到技术实现中的关键元素：
- 事件 → 消息队列中的事件消息（如 Kafka、RabbitMQ）。
- 聚合 → 微服务中的一致性边界（一个聚合通常对应一个微服务或一个限界上下文）。
- 命令 → API 接口或消息命令（Command Message）。
- 外部系统 → 第三方服务或遗留系统。
通过以上流程，团队可以在数小时内完成从业务混沌到结构化领域模型的转变，为后续的分布式事务设计（如 Saga、事件溯源、CQRS）奠定坚实的业务基础。