2. 事件风暴基础：什么是事件风暴、核心元素
2.1 什么是事件风暴
事件风暴（Event Storming）是由 Alberto Brandolini 提出的一种协作式、基于工作坊的建模方法。它通过将领域专家、技术团队和业务分析师聚集在同一面“墙”前，使用彩色便签纸快速、直观地探索和建模复杂的业务领域。其核心思想是：以“领域事件”为时间轴，逆向推导出触发事件的“命令”，并围绕命令识别出执行命令所需的“聚合”与“角色”。
在分布式事务架构选型中，事件风暴的价值尤为突出：它帮助团队在早期就识别出业务边界、一致性需求以及潜在的分布式事务场景，从而为后续的架构决策提供坚实的业务依据。
核心价值： 事件风暴不是一种编程技术，而是一种认知对齐工具。它让所有参与者对“系统到底发生了什么”达成共识，这是设计可靠分布式事务的前提。
2.2 核心元素详解
事件风暴画布由四种核心元素构成，它们共同描述了业务的全貌。下表总结了每种元素的定义、颜色约定（在物理便签中）及其在分布式事务中的意义：
| 元素 | 便签颜色 | 定义 | 分布式事务中的意义 |
|---|---|---|---|
| 领域事件 | 橙色 | 发生在业务领域中的、已经发生的、不可改变的事实。通常使用过去时态描述，如“订单已创建”、“库存已扣减”。 | 代表事务的最终状态或补偿触发点。例如，“库存扣减失败”事件可能触发Saga的补偿事务。 |
| 命令 | 蓝色 | 由角色发起的、意图改变系统状态的指令。命令可能成功（产生领域事件）或失败（产生异常事件）。 | 代表事务的发起动作。例如，“提交订单”命令可能启动一个跨服务的TCC或Saga事务。 |
| 聚合 | 黄色 | 领域驱动设计（DDD）中的概念，是一组具有内聚性的领域对象的集合，是数据一致性的边界。聚合根是外部访问的唯一入口。 | 代表事务的操作对象和一致性边界。一个分布式事务通常涉及多个聚合的最终一致性协调。 |
| 角色 | 粉色/灰色 | 发起命令的人、系统或外部参与者。角色是命令的“主语”。 | 代表事务的发起者或参与者。例如，“用户”角色发起支付命令，“支付网关”角色响应回调事件。 |
2.3 核心关系与建模流程
事件风暴的建模流程遵循一个清晰的“时间线”逻辑。下图展示了从角色到命令，再到事件和聚合的核心关系：
2.4 在分布式事务场景中的映射
理解核心元素后，我们需要将它们映射到分布式事务的典型场景中。以下是一个“订单-库存-支付”的经典案例，展示了如何通过事件风暴识别事务边界：
- 识别领域事件： 团队在时间线上贴出“订单已提交”、“库存已预占”、“支付已处理”、“订单已确认”等橙色便签。
- 逆向推导命令： 针对“库存已预占”事件，推导出“预占库存”命令；针对“支付已处理”事件，推导出“处理支付”命令。
- 识别聚合与角色： 确定“订单聚合”、“库存聚合”、“支付聚合”作为一致性边界；确定“用户”和“支付网关”作为角色。
- 发现事务边界： 当发现“订单已提交”事件需要同时保证“库存已预占”和“支付已处理”时，就识别出了一个需要分布式事务协调的场景。
实践提示： 在事件风暴工作坊中，不要过早陷入技术细节。先专注于“发生了什么”和“谁发起了什么”，事务的技术选型（如Saga、TCC、2PC）是在后续步骤中根据业务一致性要求决定的。
2.5 聚合：分布式事务的一致性边界
在分布式事务架构中，聚合是最关键的元素。它定义了数据一致性的最小单元。一个聚合内部的操作是强一致的（通常通过本地事务实现），而跨聚合的操作则需要通过最终一致性（如事件驱动）或分布式事务协议来协调。
下图展示了聚合作为一致性边界在分布式事务中的作用：
架构警示： 不要试图在一个聚合内包含所有数据。过大的聚合会导致性能瓶颈和事务冲突。事件风暴的核心价值之一就是帮助团队识别出合理的聚合粒度，从而在分布式事务中实现“高内聚、低耦合”。
2.6 小结：事件风暴与分布式事务的桥梁
事件风暴为分布式事务架构提供了业务层面的“第一性原理”。通过识别领域事件、命令、聚合和角色，团队能够：
- 明确事务边界： 知道哪些操作必须在同一个聚合内（强一致），哪些可以跨聚合（最终一致）。
- 识别补偿逻辑： 通过“逆向事件”（如“库存扣减失败”）来设计Saga的补偿步骤。
- 统一团队语言： 业务人员和技术人员使用相同的便签和术语，减少沟通误差。