DDD Event Storming

Event Storming (事件风暴) 是由 Alberto Brandolini 发明的协作式领域探索工作坊方法论。通过跨角色（领域专家 + 技术团队）的即时贴协作，在短时间内完成复杂业务领域的建模，产出聚合、限界上下文和领域事件。

Workflow

6-Step Event Storming Workshop (约 2.5 小时):

1. Step 1: 混沌探索 (30min) — 自由发散，贴出所有领域事件（🟠 橙色便签）
2. Step 2: 时间线排序 (20min) — 按时间顺序排列事件，识别主线与分支
3. Step 3: 关键事件标记 (15min) — 标记业务流程的转折点（★ 标记）
4. Step 4: 命令与角色 (30min) — 为每个事件补全命令 + 角色
5. Step 5: 聚合发现 (30min) — 聚类相关事件为聚合，命名聚合根
6. Step 6: 限界上下文划分 (20min) — 按耦合度划分 BC，确定上下文映射

产出物: 事件时间线 / 聚合候选 / BC 映射 / Hot Spots

参与角色: 领域专家(2-3人) / 开发(2-3人) / 产品(1人) / 架构师(1人)

When to Use

Skill Boundary

Audience

This skill is designed for: Backend developers (implementing DDD architectures), Software architects (evaluating and selecting patterns), Tech leads (reviewing team implementations), and DDD beginners (learning domain-driven design fundamentals).

6-Step 流程详解

Step 1: 混沌探索 — 30 min

参与者自由发散，用 🟠 橙色便签 贴出所有已知领域事件（动词过去式，如 OrderPlaced）。禁止讨论——主持人必须严格执行"先贴再说"原则。

活动: 自由贴出领域事件
格式: 动词过去式 (OrderPlaced, PaymentCompleted)
规则: 不讨论、不质疑、不排序
目标: 覆盖所有业务场景，包括异常流

Step 2: 时间线排序 — 20 min

将所有 🟠 事件便签按时间顺序排列，识别主线与分支。主线用箭头连接，异常流从主线分叉标注条件。

Step 3: 关键事件标记 — 15 min

标记业务流程的转折点，这些是关键事件（★ 标记），是领域模型的核心锚点。特征：触发后续流程、改变实体状态、跨上下文通信。

Step 4: 命令与角色 — 30 min

为每个事件添加 🔵 蓝色命令（触发动作）和 🟡 黄色角色（执行者）。自动触发的事件也有命令发起者（System、Scheduler、ExternalSystem）。

👤 Customer  →  🔵 Create Order     →  🟠 OrderPlaced
👤 Admin     →  🔵 Approve Refund   →  🟠 RefundApproved
🤖 System    →  🔵 Deduct Stock     →  🟠 InventoryDeducted

Step 5: 聚合发现 — 30 min

将相关的事件、命令聚类为聚合，并用业务语言命名聚合根。聚合是事务一致性边界——边界内强一致，边界间最终一致。

┌─ Order Aggregate ────────────────────────┐
│ 🟠 OrderPlaced / 🟠 OrderPaid           │
│ 🟠 OrderCancelled / 🟠 OrderCompleted   │
│ 🔵 PlaceOrder / 🔵 PayOrder             │
│ 👤 Customer                              │
│ 聚合根: Order  |  不变式: 已取消不可支付  │
└──────────────────────────────────────────┘

Step 6: 限界上下文划分 — 20 min

根据聚合间的耦合度和业务语言变化划出 BC 边界，标注映射关系。上下文映射类型：Partnership、Shared Kernel、Customer-Supplier、Conformist、Anti-Corruption Layer、Open Host Service。

便签颜色规范

Workshop Outputs

产出物：Event Timeline (Mermaid 序列图)、Aggregate Candidates、Bounded Context Map (Mermaid C4 图)、Context Mapping、Hot Spot List、Ubiquitous Language 术语表。

Facilitation Tips

• 会前: 准备 5+ 色便签 + 大白板/Miro 模板；必须确保领域专家参与；明确工作坊范围；提前 5 分钟介绍颜色规范和流程
• 会中: Step 1 禁止讨论（最常见的失败原因）；用业务语言优先；Hot Spot 用紫色便签标记不现场解决；严格时间盒管理；注意保持能量
• 会后: 立刻拍照存档；24h 内将产出数字化为领域文档；安排 Hot Spot 跟进会；将产出物作为 ddd-domain-designer 的输入

Online Tool Recommendations

Miro（分布式团队，推荐）| Mural（视频会议集成）| draw.io（免费轻量）| Physical Whiteboard（同地团队首选）

Relationship with ddd-domain-designer

推荐路径: event-storming (工作坊产出) → domain-designer (聚合详细设计 + 代码落地) → Architecture Skill (架构实现)

event-storming 聚焦协作工作坊主持（领域专家 + 全体团队），产出便签墙、事件列表、BC 划分（概念级）；domain-designer 聚焦开发者聚合设计（开发者 + 架构师），产出代码结构、聚合类、仓储接口（代码级）。

Customization

Quick Start

直接把需求发给 AI，以下开场白可直接使用：

"帮我组织一个电商订单履约的事件风暴工作坊，需要 6 步流程"
"我要做一个保险投保领域的事件风暴，领域专家有 2 位"
"做一次用户中台的事件风暴，重点关注认证和权限"
"之前做完了物流配送的事件风暴，帮我整理产出物"

如果你不确定从哪里开始，直接说"帮我做事件风暴"，AI 会自动引导你完成。

Security & Safety

This skill is pure documentation. It contains no executable scripts, collects no user data, accesses no external services or networks.

Gotchas — Common Pitfalls

1. 跳过 Brainstorming 直接讨论: 必须先自由发散再排序。过早讨论事件正确性会扼杀创意。
2. 技术人员主导: 必须由领域专家主导，开发做记录和提问。开发主导的模型不是真实业务。
3. CRUD 式命令: 不要写 "CRUD Order"，命令应该是业务动作：PlaceOrder、CancelOrder。
4. 遗忘 Hot Spot: 所有分歧和不确定的边界必须记录为紫色便签。不记录的 Hot Spot 会后被遗忘。
5. 跳过 Aggregate Discovery: 做完 Step 4 就结束。没有 Step 5 的聚类，事件风暴只是漂亮的便签墙。
6. 领域专家缺失: 这是致命错误。没有领域专家参与事件风暴会产出错误的领域模型。
7. 试图一次覆盖整个企业: 范围太大会导致浅尝辄止。建议从核心子域开始，一个 BC 一次。
8. 产出物不整理 → 便签墙变装饰品: 工作坊结束后 24h 内必须将产出数字化，否则记忆会丢失。用 workshop-output-template.md 模板快速整理。
9. 没有通用语言记录: 风暴中自然产生的术语定义的共识，必须记录下来成为 Ubiquitous Language 表。不记录等于没达成共识。

FAQ

References

详情见 references/ 和 examples/：

• Templates: sticky-note-template.md, timeline-example.md, workshop-output-template.md
• Guides: facilitation-checklist.md, workshop-deep-guide.md, context-mapping.md, partme-12-event-storming-modeling.md, ddd-strategic.md, clean-ddd-hexagonal-strategic.md
• Examples: 5 个工作坊案例（电商订单履约、保险投保、用户中台、物流配送、金融支付）