Event Storming（事件风暴）
解决什么问题：业务和技术团队没有共同语言——业务说"流程"，技术说"服务"——Event Storming 是一个2-4 小时的工作坊，让所有人用"领域事件"对齐认知，直接产出通用语言 + BC 边界。
它是什么
Event Storming 是 Alberto Brandolini 发明的工作坊方法——业务专家 + 技术团队围着一面墙，用便利贴画整个业务流程：
- 橙色便利贴 = 领域事件（过去式：OrderCreated / OrderPaid）
- 黄色便利贴 = 命令（触发事件的动词：CreateOrder / PayOrder）
- 蓝色便利贴 = 聚合（执行命令的对象）
- 粉色便利贴 = 外部系统
- 绿色便利贴 = 读模型（用户视图）
- 紫色便利贴 = 问题 / 风险
按时间线从左到右铺开，最后用空间边界 = BC 边界。
Brandolini 原话： "The whole point of Event Storming is to bring people together... so they can discover what they don't know."
V2 视角（V2.7 B1 段 4 改造后）：Event Storming = B1 认识对象 + B2 认识自己 + B3 分解 + B4 抽象的四合一工作坊——用一个会议，把"它是什么 / 我们怎么理解 / 怎么切 / 共性在哪"全部完成。
关键属性
| 属性 | 值/含义 |
|---|---|
| 参与者 | 业务专家 + 开发 + 测试 + 产品（10-20 人最理想） |
| 时长 | 2-4 小时（Big Picture）/ 1-2 天（Process Modeling） |
| 物料 | 便利贴（多色）+ 大白墙 + 马克笔 |
| 起点 | 一个核心领域事件（如 OrderCreated） |
| 产出 | 领域事件清单 + 命令清单 + 聚合清单 + BC 边界 |
| 三种级别 | Big Picture / Process Modeling / Software Design |
| 反模式 | 单纯技术团队参与（没有业务专家） |
| 核心约束 | 一次只画一个 BC 的流程——不要试图画全公司 |
怎么用
场景 1：Big Picture Event Storming（最常用）
目的：识别 BC 边界。
步骤：
- 邀请业务专家（最懂业务的人）+ 技术团队 + 产品
- 找一个空白大墙（6 米宽以上）
- 业务专家从左到右贴橙色便利贴——所有"过去发生的事"，用过去式
- 识别触发者——每个事件左边贴黄色便利贴（命令）
- 识别执行者——每个命令右边贴蓝色便利贴（聚合 / Actor）
- 找热点——多人挤在同一区域 = BC 边界候选
- 画边界——用虚线框出 BC
- 标注关系——BC 之间用 Context Map 关系标注
产出：BC 边界图 + 领域事件清单 + 初步通用语言。
场景 2：Process Modeling Event Storming（深入流程）
目的：在一个 BC 内部详细画流程。
步骤：
- 在 Big Picture 基础上，选一个 BC
- 加粉色便利贴（外部系统触发）
- 加绿色便利贴（读模型 / 用户视图）
- 加紫色便利贴（问题 / 风险 / 政策）
- 检查不变性——哪些事件必须原子发生？同一事务内的事件 = 同一聚合
产出：BC 内部的详细流程图 + 聚合根清单 + 不变量清单。
场景 3：Software Design Event Storming（落地代码）
目的：把流程映射到代码模型。
步骤：
- 把蓝色便利贴（聚合）转换为聚合根 class
- 把橙色便利贴（事件）转换为Domain Event class
- 把黄色便利贴（命令）转换为Command / Service 方法
- 把粉色便利贴（外部系统）转换为防腐层 Adapter
- 逐个写测试——一个事件 = 一个测试用例
产出：完整的领域模型代码 + 测试用例。
场景 4：发现"暗债"业务
目的：用 Event Storming 诊断遗留系统。
步骤：
- 让业务专家画"理想流程"
- 让开发画"现实流程"
- 对比——理想与现实的差距 = 暗债
- 优先级排序——紫色便利贴（问题）数量 = 暗债严重度
常见误区
- "Event Storming = 需求评审会"——错。Event Storming 是探索性工作坊，不是评审。目的是发现未知，不是确认已知
- "技术团队单独做"——错。没有业务专家 = 瞎猜。业务专家必须在场，否则产物是技术幻觉
- "一次画完所有 BC"——错。一次只画一个 BC（或一个核心域），否则信息过载
- "用 Visio 画"——错。便利贴的物理移动 = 认知修正。电子画板会失去"重新排列"的便利性。用真的墙 + 真的便利贴
- "时间 = 30 分钟"——错。Big Picture 最少 2 小时。匆忙 = 错过关键细节
- "产出 = 完美的 BC 图"——错。Event Storming 的真正产出是通用语言共识 + BC 边界假设——后者需要后续验证
关键洞察
Event Storming 不是"画图技术"——它是"组织工程"——把分散在各人脑子里的业务认知汇聚成共享模型。
- 通用语言在讨论中产生（不是文档里规定）
- BC 边界在空间分布中显形（不是纸上规划）
- 不变量在反复追问中暴露（不是代码里实现）
这是 V2.7 B1（认识对象）+ B3（分解）的工作坊实现——协作即建模。
判断 Event Storming 是否成功的标准 = 结束后，业务专家说"这个图就是我们公司的业务"，开发说"我知道代码怎么写了"。
相关链接
- Bounded Context——Event Storming 的核心产出
- Ubiquitous Language——Event Storming 的副产品
- Bounded Context Canvas——单 BC 详细分析工具
- [V3 涌现视域] · 认识对象——Event Storming = B1 工作坊
- 源典 IDDD Ch 2——Vernon 对 Big Picture 的描述