事件风暴基础：什么是事件风暴、核心角色
事件风暴（Event Storming）是由 Alberto Brandolini 提出的一种协作建模技术，它通过高密度、高互动的工作坊形式，让领域专家与技术人员在同一个画布上快速发现业务全貌。在分布式事务设计中，事件风暴是连接业务需求与技术实现的桥梁——它帮助我们识别哪些业务操作需要跨服务的一致性保障，哪些可以容忍最终一致性。
2.1 什么是事件风暴
事件风暴是一种基于“事件”的轻量级建模方法，核心思想是：业务行为的结果就是领域事件。工作坊中，参与者使用不同颜色的便利贴，在时间轴上从左到右排列出业务发生的完整流程。
| 特征 | 说明 |
|---|---|
| 协作性 | 领域专家、产品经理、开发人员、测试人员共同参与 |
| 时间顺序 | 事件按发生的时间线从左到右排列 |
| 可视化 | 使用彩色便利贴区分不同角色，一目了然 |
| 探索性 | 不追求完美，快速暴露认知差异和业务盲区 |
| 可扩展 | 从大流程到细节，逐步深入 |
实践提示：在分布式事务场景中，事件风暴特别适合用来识别“跨边界的事务边界”。当两个聚合之间需要保证数据一致性时，事件风暴画布上的橙色命令和蓝色事件会清晰暴露出这个“断点”。
2.2 核心角色详解
事件风暴画布上共有五种核心角色，每种角色用特定颜色的便利贴表示。理解这些角色是进行领域事件建模的前提。
2.2.1 领域事件（Domain Event）—— 橙色
领域事件是已经发生的业务事实，用过去时态命名。它是事件风暴的起点，也是分布式事务中需要保证传递的消息。
- 命名规范：动词过去式 + 业务名词，例如
OrderSubmitted、PaymentReceived、InventoryReserved - 特征：不可变、有发生时间、对业务有意义
- 在分布式事务中的作用：作为消息在服务间传递，驱动 Saga 或事件驱动架构的下一步操作
2.2.2 命令（Command）—— 蓝色
命令是触发领域事件的用户意图或系统请求。它代表“有人想做某事”，但尚未发生。
- 命名规范：动词原形 + 业务名词，例如
SubmitOrder、MakePayment、ReserveInventory - 特征：可能被拒绝、需要校验权限和业务规则
- 与领域事件的关系：一个命令成功执行后，会产生一个或多个领域事件
2.2.3 聚合（Aggregate）—— 黄色
聚合是领域模型中保证数据一致性的基本单元。它封装了业务实体和业务规则，是命令的执行者。
- 特征：有唯一标识、有生命周期、内部强一致
- 在分布式事务中的关键作用：聚合边界决定了事务的边界。跨聚合的操作通常需要引入 Saga 或 TCC 模式
- 示例：
Order聚合包含订单项、金额、状态，所有修改必须通过Order聚合根
2.2.4 策略（Policy）—— 紫色
策略是当某个领域事件发生时，自动触发后续命令的业务规则。它是事件驱动架构的核心连接器。
- 命名规范：When + 事件 + Then + 命令，例如
When OrderSubmitted Then SendConfirmationEmail - 特征：无状态、响应式、可独立测试
- 在分布式事务中的应用：实现 Saga 的补偿逻辑、超时处理、异步通知
2.2.5 读模型（Read Model）—— 绿色
读模型是为用户或外部系统展示数据的投影。它不参与业务逻辑，只负责查询和展示。
- 特征：可重复构建、可缓存、与写模型分离
- 在分布式事务中的作用：提供最终一致性的查询视图，例如“订单状态追踪页面”
- 示例：
OrderSummaryView、PaymentHistoryReadModel
核心记忆口诀：蓝色命令发起，橙色事件发生，黄色聚合执行，紫色策略响应，绿色读模型展示。
2.3 核心角色关系图
下图展示了五种核心角色在事件风暴画布上的典型协作关系：
2.4 角色对比速查表
| 角色 | 颜色 | 时态 | 是否可拒绝 | 分布式事务中的角色 |
|---|---|---|---|---|
| 领域事件 | 橙色 | 过去时（已发生） | 否（事实不可撤销） | 消息载体，驱动 Saga 步骤 |
| 命令 | 蓝色 | 现在时（意图） | 是（可校验失败） | 事务发起入口 |
| 聚合 | 黄色 | 持续存在 | — | 事务边界，保证强一致性 |
| 策略 | 紫色 | 条件触发 | — | Saga 编排器、补偿逻辑 |
| 读模型 | 绿色 | 最终一致 | — | 提供事务状态的查询视图 |
2.5 事件风暴工作坊的典型流程
一次标准的事件风暴工作坊通常包含以下步骤：
- 混沌探索：参与者自由地在画布上贴出所有能想到的领域事件（橙色），不讨论对错
- 时间线排序：将事件按业务发生的时间顺序从左到右排列，形成主干流程
- 插入命令：在每个事件左侧贴上触发它的命令（蓝色），明确“谁发起了什么”
- 识别聚合：在命令和事件之间贴上执行该命令的聚合（黄色），确定事务边界
- 添加策略：在需要自动响应的事件右侧贴上策略（紫色），识别异步流程
- 补充读模型：在需要查询展示的位置贴上读模型（绿色），明确查询需求
- 边界划分：根据聚合和事件流，识别限界上下文（Bounded Context），确定服务拆分方案
常见误区：初学者容易把“命令”和“事件”混淆。记住一个简单的判断方法：如果这个动作可能被拒绝（例如余额不足导致支付失败），那它就是命令；如果这个动作已经发生且不可撤销（例如支付成功），那它就是领域事件。在分布式事务中，只有领域事件才应该作为消息在服务间传递。
2.6 本章小结
事件风暴通过五种核心角色（领域事件、命令、聚合、策略、读模型）将复杂的业务逻辑可视化。在分布式事务建模中，这些角色帮助我们：
- 用领域事件定义事务的每个步骤和补偿操作
- 用命令明确事务的触发入口
- 用聚合划定强一致性边界
- 用策略实现 Saga 的自动编排和超时处理
- 用读模型提供最终一致性的查询能力