2. 事件风暴基础：起源、核心概念与工作坊流程
事件风暴（Event Storming）是由 Alberto Brandolini 于 2013 年提出的一种协作建模技术。它通过高密度、高互动的工作坊形式，让业务专家与开发团队在短时间内共同发现业务全貌，并以此驱动领域驱动设计（DDD）与分布式系统架构的落地。本章将系统梳理事件风暴的起源、核心概念以及标准工作坊流程，为后续使用事件风暴画布进行分布式事务架构选型奠定坚实的认知基础。
2.1 事件风暴的起源与设计哲学
事件风暴诞生的背景是传统需求分析与架构设计之间的鸿沟。Brandolini 观察到：
- 文档驱动的需求规格说明书往往在编写完成时就已经过时；
- 单向沟通导致业务专家与开发团队对同一概念的理解存在巨大偏差；
- 技术过早介入使得系统架构无法真实反映业务复杂度。
事件风暴的核心设计哲学可以概括为以下三点：
| 设计哲学 | 核心主张 | 对分布式架构的影响 |
|---|---|---|
| 协作优先 | 所有参与者（业务、产品、开发、测试）围在同一张画布前，使用统一语言建模 | 消除信息孤岛，确保分布式事务的边界定义来自业务共识 |
| 事件驱动 | 以“已经发生的事情”为建模起点，而非“系统应该做什么” | 天然适配事件溯源、消息队列、Saga 等分布式事务模式 |
| 时间线可视化 | 按时间顺序从左到右排列事件，形成完整的业务流 | 清晰暴露跨限界上下文的时序依赖，为分布式事务选型提供依据 |
实践提示： 事件风暴不是 UML 的替代品，而是一种“建模加速器”。在分布式事务场景中，它最大的价值在于让团队在 2-4 小时内识别出哪些操作必须保证原子性、哪些可以最终一致。
2.2 核心概念详解
事件风暴画布上使用不同颜色的便签（Sticky Notes）来区分不同的建模元素。以下是五个核心概念的定义、颜色约定及在分布式事务中的角色：
2.2.1 事件（Event）
- 定义： 业务领域中已经发生的、不可改变的事实。通常使用过去时态命名，例如“订单已创建”、“支付已成功”。
- 画布颜色： 橙色
- 分布式事务角色： 事件是 Saga 编排模式的核心驱动单元。每个本地事务完成后发布一个事件，触发下一个步骤或补偿操作。
2.2.2 命令（Command）
- 定义： 用户或外部系统发出的、意图改变系统状态的请求。通常使用祈使句命名，例如“创建订单”、“支付订单”。
- 画布颜色： 蓝色
- 分布式事务角色： 命令是分布式事务的入口点。在 TCC（Try-Confirm/Cancel）模式中，Try 阶段接收的命令决定了后续 Confirm 或 Cancel 的路径。
2.2.3 聚合（Aggregate）
- 定义： 领域驱动设计中的一致性边界。一个聚合是一组相关对象的集合，外部只能通过聚合根访问内部对象。聚合内的所有变更必须在同一个事务中完成。
- 画布颜色： 黄色（通常使用大号便签）
- 分布式事务角色： 聚合是分布式事务的“最小原子单元”。一个分布式事务通常跨越多个聚合，每个聚合内部保证强一致性，聚合之间通过最终一致性协调。
2.2.4 限界上下文（Bounded Context）
- 定义： 领域驱动设计中划分模型边界的核心模式。每个限界上下文拥有独立的通用语言、数据库和微服务（或模块）。
- 画布颜色： 通常使用透明胶带或虚线框在画布上圈定范围。
- 分布式事务角色： 限界上下文是分布式事务的“物理边界”。跨限界上下文的事务必须采用 Saga、TCC 或可靠消息等分布式事务方案，而不能依赖本地数据库事务。
2.2.5 角色（Actor）与外部系统
- 定义： 触发命令的人或系统。例如“客户”、“支付网关”、“库存系统”。
- 画布颜色： 绿色（小号便签）
- 分布式事务角色： 识别外部系统有助于判断分布式事务的“可信边界”。例如，支付网关的回调结果可能不可靠，需要引入幂等和重试机制。
关键区分： 事件与命令是事件风暴中最容易混淆的一对概念。记住一个简单的判断标准：命令是“我想做”，事件是“已做完”。在分布式事务建模中，命令对应 Try 阶段，事件对应 Confirm 阶段。
2.3 工作坊流程：从混乱到共识
一个标准的事件风暴工作坊通常分为三个阶段，每个阶段都有明确的产出物和参与角色。以下流程经过大量分布式系统项目的验证，特别适合用于分布式事务架构选型的前置建模。
2.3.1 第一阶段：混沌探索（Chaotic Exploration）
- 目标： 在不受技术约束的前提下，穷举所有业务事件。
- 参与角色： 业务专家（主导）、领域专家、产品经理。
- 步骤：
- 在画布最左侧贴上“开始”标记，最右侧贴上“结束”标记。
- 所有参与者自由地在画布上贴橙色事件便签，按时间顺序从左到右排列。
- 不讨论细节，不删除任何事件，鼓励“过度生成”。
- 产出： 一张覆盖完整业务生命周期的事件时间线。
2.3.2 第二阶段：命令与聚合识别（Command & Aggregate Identification）
- 目标： 为每个事件找到触发它的命令，并识别出事件所属的聚合。
- 参与角色： 业务专家 + 开发团队（共同参与）。
- 步骤：
- 在每个事件左侧贴上蓝色命令便签，回答“是什么操作导致了该事件的发生？”
- 将紧密相关的事件和命令圈入黄色聚合便签，每个聚合代表一个事务一致性边界。
- 使用紫色虚线框圈定限界上下文，将聚合归入对应的上下文。
- 产出： 包含事件、命令、聚合和限界上下文的完整画布。
2.3.3 第三阶段：热点与边界决策（Hotspot & Boundary Decision）
- 目标： 识别跨限界上下文的交互点，为分布式事务选型提供决策依据。
- 参与角色： 架构师（主导）、开发团队、业务专家（确认）。
- 步骤：
- 用红色“热点”便签标记所有跨限界上下文的事件流。
- 针对每个热点，讨论并记录：是否需要强一致性？是否可以接受最终一致性？
- 在画布上标注出 Saga、TCC、可靠消息等候选分布式事务模式。
- 产出： 标注了分布式事务策略的事件风暴画布，可直接用于后续的架构选型决策。
常见陷阱： 在第二阶段过早引入技术细节（如消息队列、数据库类型）会严重拖慢工作坊节奏。请务必遵循“先业务、后技术”的原则。分布式事务的选型决策应严格在第三阶段进行。
2.4 事件风暴与分布式事务架构选型的衔接
事件风暴的产出物——标注了限界上下文、聚合和跨边界事件流的画布——是分布式事务架构选型的直接输入。下表总结了画布上的典型模式与对应的分布式事务方案：
| 画布特征 | 业务含义 | 推荐的分布式事务方案 | Go 工程实践方向 |
|---|---|---|---|
| 事件流完全在同一个限界上下文内 | 无跨服务依赖 | 本地事务（ACID） | GORM + 数据库事务 |
| 跨限界上下文的事件流为“线性链” | 步骤之间有严格顺序，但允许最终一致 | 编排 Saga | Go 协程 + 消息队列（Kafka/RabbitMQ） |
| 跨限界上下文的事件流包含“回滚路径” | 业务要求失败时撤销已执行的操作 | choreography Saga 或 TCC | Go 实现 Try/Confirm/Cancel 接口 |
| 跨限界上下文的事件流需要“即时一致性” | 业务要求强一致性，不能接受最终一致 | 可靠消息 + 本地事务表 | Go 定时任务 + 消息去重 |
| 多个聚合共享同一个事件源 | 事件溯源模式 | 事件溯源 + CQRS | Go Event Store + 投影 |
课程衔接： 本章建立的事件风暴基础概念和工作坊流程，将在第 3 章《事件风暴画布详解》中进一步展开为可操作的建模模板。第 4-8 章将分别针对上表中的每种分布式事务方案，结合 Go 语言进行深度实践。