microwind 事件风暴建模 (Event Storming)
概述
事件风暴 (Event Storming) 是意大利人 Alberto Brandolini 于 2012 年提出的一种交互式领域建模工作坊方法。通过将业务方、产品、开发、测试等不同背景的人聚在一起，使用彩色便利贴在大白板（或大墙）上发散 - 收敛地梳理业务逻辑，最终形成统一语言和领域模型。
核心特征：
- 以"事件"为核心 —— 事件是业务行为留下的"印记"，一串事件就能还原业务流程
- 多角色共建 —— 有问题的人（开发、测试）+ 有答案的人（业务、产品）同时到场
- 边玩边学 —— 站着讨论、随时重贴，促进沉浸式共创
- 输出即起点 —— 产出的事件流直接作为领域模型、架构设计的基础
事件风暴的彩色语法
事件风暴使用一套统一的彩色贴纸语法，每种颜色代表一种领域概念。
| 颜色 | 概念 | 含义 |
|---|---|---|
| 橙色 | Event（事件） | 已发生且业务关注的事情，用过去式描述，如"订单已支付" |
| 蓝色 | Command（命令） | 由行动者发起的动作，触发事件，如"提交订单" |
| 浅黄色 | Actor（行动者） | 系统使用者，可以是人或外部系统 |
| 紫色 | System（系统） | 作为黑盒看待的三方系统 |
| 绿色 | Read Model（阅读模型） | 支持决策所需信息，常对应界面视图 |
| 粉色 | Policy（策略 / 业务规则） | 事件触发的响应规则，可触发新命令（SIC） |
| 红色 | HotSpot（热点问题） | 业务痛点、瓶颈、模糊点，需后续澄清 |
行动者 ──触发──▶ 命令 ──执行──▶ 事件 ──触发──▶ 策略 ──派发──▶ 新命令
│
└──▶ 阅读模型 (用户参考)
事件风暴工作坊流程
准备阶段
1. 物料：彩色便利贴、白板/大墙面、马克笔；不放椅子，让大家站着参与
2. 人员：
├── 有答案的人：业务专家、产品经理、用户代表
└── 有问题的人：开发、架构师、测试、设计
3. 主持人：引导流程、保持专注、用提问驱动、总结收敛
4. 范围：开场时明确"本次讨论什么业务场景，目标是什么"
第一步：梳理事件（橙色）
从一个"种子事件"开始，通过提问不断向前后扩展：
提问技巧：
▸ "这个事件发生前，有什么事件？"
▸ "这个事件之后，下一步会发生什么？"
▸ "这个事件一定会成功吗？失败会产生什么事件？"
时间顺序：左 → 右
[订单已创建] → [订单已支付] → [专栏已订阅] → [已学习课程]
别忘了 Unhappy Path：
[订单已创建] ─失败─▶ [订单创建失败]
[支付已发起] ─超时─▶ [支付超时] ─补偿─▶ [订单已关闭]
第二步：业务规则（粉色）
围绕每个事件挖掘触发条件和后续影响：
提问：
▸ "事件一定成功吗？前提条件是什么？"
▸ "事件发生后会引发什么？"
示例（"订单已创建"事件的规则）：
▸ 前提：专栏可订阅 + 用户未订阅过该专栏
▸ 后果：自动发起支付流程
第三步：行动者 / 命令 / 阅读模型 / 系统
提问：
▸ "是什么触发了事件？命令 or 规则？"
▸ "谁执行了动作？人 or 系统？"
▸ "做动作前，用户需要看到哪些信息？（阅读模型）"
▸ "是否依赖外部系统？"
典型流：
读者(Actor) ─提交订单(Command)──▶ 订单已创建(Event)
└─触发(Policy)─▶ 发起支付(Command)
└─调用─▶ 支付网关(System)
第四步：热点问题（红色）
凡是有分歧、模糊、需要业务方回去确认的点，统一用红色记录，不要在工作坊里试图解决所有 HotSpot。
第五步：故事串讲
请一位成员按时间顺序把整条事件流"讲出来"，其他人听并挑战。不一致处停下来讨论调整。
第六步：产出架构
基于事件流产出：
- 领域模型（聚合、实体、值对象）
- 用例图、状态图、活动图、时序图
- 限界上下文划分（事件聚类即上下文边界线索）
实战示例：RabbitAdvisors "订阅专栏"
时间线 ────────────────────────────────────────────────────────────▶
[读者] ─(浏览专栏)─▶ [专栏列表已展示] ← Read Model
│
[读者] ─(点击订阅)─▶ [订单已创建] ← Policy: 专栏可订阅 & 用户未订阅
│
└─SIC─▶ [支付已发起] ─调用─▶ (支付网关)
│
├─成功─▶ [订单已支付]
│ └─▶ [专栏已订阅]
│ └─▶ [积分已增加] ← 成长域策略
│
└─超时─▶ [支付超时]
└─▶ [订单已关闭]
HotSpot (红色)：
▸ 专栏涨价后，已订阅用户的权益如何处理？
▸ 作者下架专栏时，已订阅用户能继续看多久？
事件风暴的优点与局限
优点：
- 低门槛：用便利贴即可开始，不需要 UML 等专业工具
- 高共识：业务与技术在同一块墙上对齐语言，促成统一语言
- 快速：半天到一天可完成一个子域的建模
- 产物直接可用：事件流直接对应领域事件、聚合边界
局限：
- 模式偏重：需要多角色在场，组织成本高
- 依赖主持人经验：收敛阶段的逻辑选择决定最终模型质量
- 发散阶段噪音多：需要强经验才能过滤掉无效信息
- "一学就会，一用就废"：初学者容易停在发散阶段，得不到可落地的模型
与四色建模法的对比
| 维度 | 事件风暴 | 四色建模法 |
|---|---|---|
| 起点 | 随机发散找事件 | 从现金流 / KPI 出发推导事件 |
| 逻辑 | 发散 → 收敛 | 强分析，逐步推导 |
| 人员 | 多角色工作坊 | 可以小团队甚至架构师独立完成 |
| 风险 | 收敛依赖主持人 | 要求业务有明确现金流或 KPI |
| 适用 | 业务不明朗、需对齐共识 | 业务稳定、有明确商业模式 |
与其他 DDD 概念的关系
| 概念 | 关系 |
|---|---|
| 通用语言 | 事件风暴是建立通用语言的主要工作坊形式 |
| 领域事件 | 事件风暴中的橙色贴纸直接就是领域事件的原型 |
| 限界上下文 | 事件聚类与命令归属是上下文划分的依据 |
| 聚合 | 同一组事件围绕的状态边界通常即为聚合边界 |
总结
核心：以领域事件为线索，通过多角色协作把业务讲清楚。
实践：准备 → 梳理事件 → 规则 → 行动者与命令 → 记录热点 → 故事串讲 → 产出架构。
关键：工作坊产出的价值取决于主持人的收敛能力，初学者可与四色建模法结合使用以降低随意性。