# 事件风暴建模

> 通过多角色工作坊发散式探寻领域事件、命令和策略，快速建立业务共识并产出领域模型的轻量级建模方法。

- Skill: `microwind/skill-73` (Agent Skill)
- Install (CLI): `npx skillmds@latest add microwind/skill-73`
- Raw SKILL.md: https://api.skillmd.com/api/skills/microwind/skill-73/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: microwind (https://skillmd.com/u/microwind)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/microwind/skill-73

---


# 事件风暴建模 (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 等专业工具
- 高共识：业务与技术在同一块墙上对齐语言，促成统一语言
- 快速：半天到一天可完成一个子域的建模
- 产物直接可用：事件流直接对应领域事件、聚合边界

**局限**：

- **模式偏重**：需要多角色在场，组织成本高
- **依赖主持人经验**：收敛阶段的逻辑选择决定最终模型质量
- **发散阶段噪音多**：需要强经验才能过滤掉无效信息
- "**一学就会，一用就废**"：初学者容易停在发散阶段，得不到可落地的模型

## 与[四色建模法](../four-color-modeling/)的对比

| 维度 | 事件风暴 | 四色建模法 |
|------|----------|-----------|
| 起点 | 随机发散找事件 | 从现金流 / KPI 出发推导事件 |
| 逻辑 | 发散 → 收敛 | 强分析，逐步推导 |
| 人员 | 多角色工作坊 | 可以小团队甚至架构师独立完成 |
| 风险 | 收敛依赖主持人 | 要求业务有明确现金流或 KPI |
| 适用 | 业务不明朗、需对齐共识 | 业务稳定、有明确商业模式 |

## 与其他 DDD 概念的关系

| 概念 | 关系 |
|------|------|
| [通用语言](../ubiquitous-language/) | 事件风暴是建立通用语言的主要工作坊形式 |
| [领域事件](../domain-events/) | 事件风暴中的橙色贴纸直接就是领域事件的原型 |
| [限界上下文](../bounded-context/) | 事件聚类与命令归属是上下文划分的依据 |
| [聚合](../aggregate/) | 同一组事件围绕的状态边界通常即为聚合边界 |

## 总结

**核心**：以领域事件为线索，通过多角色协作把业务讲清楚。

**实践**：准备 → 梳理事件 → 规则 → 行动者与命令 → 记录热点 → 故事串讲 → 产出架构。

**关键**：工作坊产出的价值取决于主持人的收敛能力，初学者可与[四色建模法](../four-color-modeling/)结合使用以降低随意性。