1. 事件风暴画布基础：起源、核心概念与布局规则
1.1 事件风暴的起源
事件风暴（Event Storming）由 Alberto Brandolini 于 2013 年提出，是一种基于工作坊的协作建模方法。其诞生背景源于传统软件需求分析中“业务专家与开发团队之间的认知鸿沟”——业务方用自然语言描述流程，而技术方用类图、用例图等抽象模型沟通，双方在翻译过程中频繁丢失关键细节。
Brandolini 受领域驱动设计（DDD）启发，提出“用事件驱动思维统一语言”：让所有参与者围在一张巨大的白板（或画布）前，用彩色便利贴逐步还原业务全流程。这种“高密度、低仪式感”的协作方式迅速在 DDD 社区普及，成为探索复杂业务领域、发现限界上下文、设计聚合与事件驱动架构的首发技术。
核心洞察： 事件风暴不是 UML 替代品，而是一种“认知加速器”——通过物理空间中的即时反馈，迫使团队在数小时内暴露业务中隐藏的假设、异常路径和一致性边界。
1.2 核心概念
事件风暴画布围绕三个基本构造块展开：领域事件、命令和聚合。三者构成“命令 → 聚合 → 事件”的因果链，是后续分布式事务建模的原子单元。
| 概念 | 便利贴颜色 | 定义 | 示例 |
|---|---|---|---|
| 领域事件 | 橙色 | 业务领域中已经发生的、不可撤销的事实。通常使用过去时态命名。 | 订单已提交、库存已扣减、支付已成功 |
| 命令 | 蓝色 | 触发领域事件的用户意图或系统指令。命令可能被拒绝（违反业务规则）。 | 提交订单、扣减库存、执行支付 |
| 聚合 | 黄色（大号） | 保证业务一致性的数据与行为边界。聚合内所有变更必须在一个事务中完成。 | 订单聚合、库存聚合、支付聚合 |
1.3 画布布局规则
标准事件风暴画布采用时间轴从左到右的布局，辅以泳道区分不同角色或系统。以下为布局核心规则：
- 时间主线：领域事件按发生时间顺序从左向右排列，形成业务流的主干。
- 命令前置：每个领域事件左侧紧邻其触发命令，命令左侧标注执行角色（人/系统/定时器）。
- 聚合包裹：将命令与事件之间的业务逻辑用黄色聚合便利贴包裹，表示事务边界。
- 泳道分层：不同限界上下文或参与者使用水平泳道隔离，避免跨域事件混淆。
- 热点标注：红色便利贴标记“问题/风险”，紫色便利贴标记“外部系统/策略”，粉色便利贴标记“用户角色”。
布局口诀： “橙事件，蓝命令，黄聚合包逻辑；左到右，按时间，泳道隔开上下文。”
1.4 从画布到分布式事务的桥梁
事件风暴画布天然暴露了分布式事务的痛点：当橙色事件跨越多个黄色聚合（尤其是跨泳道/跨限界上下文）时，本地事务不再适用。画布上的每一个“聚合边界”都对应一个潜在的分布式事务决策点：
- 同一聚合内：使用本地 ACID 事务，无需分布式协调。
- 跨聚合但同限界上下文：可考虑最终一致性 + 本地事件表。
- 跨限界上下文（跨泳道）：必须引入 Saga、TCC、事件驱动等分布式事务模式。
常见误区： 初学者常把画布上的每个“命令”都当作独立事务入口。实际上，命令只是意图表达，真正的事务边界由黄色聚合决定——一个聚合内的多个命令可以合并为一次事务提交。