full-stack-skills DDD Event Storming
Event Storming (事件风暴) 是由 Alberto Brandolini 发明的协作式领域探索工作坊方法论。通过跨角色（领域专家 + 技术团队）的即时贴协作，在短时间内完成复杂业务领域的建模，产出聚合、限界上下文和领域事件。
Workflow
6-Step Event Storming Workshop (约 2.5 小时):
- Step 1: 混沌探索 (30min) — 自由发散，贴出所有领域事件（🟠 橙色便签）
- Step 2: 时间线排序 (20min) — 按时间顺序排列事件，识别主线与分支
- Step 3: 关键事件标记 (15min) — 标记业务流程的转折点（★ 标记）
- Step 4: 命令与角色 (30min) — 为每个事件补全命令 + 角色
- Step 5: 聚合发现 (30min) — 聚类相关事件为聚合，命名聚合根
- Step 6: 限界上下文划分 (20min) — 按耦合度划分 BC，确定上下文映射
产出物: 事件时间线 / 聚合候选 / BC 映射 / Hot Spots
参与角色: 领域专家(2-3人) / 开发(2-3人) / 产品(1人) / 架构师(1人)
When to Use
| 适用场景 | 不适用场景 |
|---|---|
| 新项目启动，需要领域建模 | 领域知识已充分文档化，直接 domain-designer |
| 已有系统重构，业务不清晰 | 单人开发，无利益相关者参与 |
| 跨团队协作，需要统一语言 | 纯技术工具开发，无业务领域 |
| 微服务拆分，需确定服务边界 | 简单 CRUD 项目，领域模型清晰 |
Skill Boundary
| 技能 | 定位 | 使用时机 |
|---|---|---|
ddd-event-storming |
工作坊主持 + 领域探索 | 项目前期，多角色协作 |
ddd-domain-designer |
聚合详细设计 + 代码映射 | 工作坊之后，开发之前 |
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。
便签颜色规范
| 颜色 | 含义 | 格式要求 | 示例 |
|---|---|---|---|
| 🟠 橙色 | Domain Event (领域事件) | 动词过去式 | OrderPaid, UserRegistered |
| 🔵 蓝色 | Command (命令) | 动词原形 | PayOrder, RegisterUser |
| 🟡 黄色 | Actor/Role (角色/参与者) | 名词 | Customer, System, Admin |
| 🟢 绿色 | Read Model (读模型/视图) | 名词 | OrderDetailPage, Dashboard |
| 🔴 粉色 | External System (外部系统) | 系统名 | Alipay, WeChatPay |
| 🟣 紫色 | Constraint/Hot Spot (约束/争议) | 业务规则语句 | Max ¥50000 per order |
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
| 场景 | 建议调整 |
|---|---|
| 小型团队(3-5人) | 合并 Step 1+2 为 20min+15min；Skip Step 6 直接讨论 |
| 大型团队(10+人) | Step 1 延长至 45min 分组并行贴便签；Step 6 增加 10min 分组汇报 |
| 时间受限(1小时) | 只做 Step 1-3（事件发散+排序），后续步骤单独安排 |
| 复杂领域(多 BC) | 每个 BC 单独一次工作坊，不要试图一次覆盖 |
| 跨语言团队 | 便签使用双语（中文事件+英文术语），以中文共识为准 |
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
- 跳过 Brainstorming 直接讨论: 必须先自由发散再排序。过早讨论事件正确性会扼杀创意。
- 技术人员主导: 必须由领域专家主导，开发做记录和提问。开发主导的模型不是真实业务。
- CRUD 式命令: 不要写 "CRUD Order"，命令应该是业务动作：
PlaceOrder、CancelOrder。 - 遗忘 Hot Spot: 所有分歧和不确定的边界必须记录为紫色便签。不记录的 Hot Spot 会后被遗忘。
- 跳过 Aggregate Discovery: 做完 Step 4 就结束。没有 Step 5 的聚类，事件风暴只是漂亮的便签墙。
- 领域专家缺失: 这是致命错误。没有领域专家参与事件风暴会产出错误的领域模型。
- 试图一次覆盖整个企业: 范围太大会导致浅尝辄止。建议从核心子域开始，一个 BC 一次。
- 产出物不整理 → 便签墙变装饰品: 工作坊结束后 24h 内必须将产出数字化，否则记忆会丢失。用
workshop-output-template.md模板快速整理。 - 没有通用语言记录: 风暴中自然产生的术语定义的共识，必须记录下来成为 Ubiquitous Language 表。不记录等于没达成共识。
FAQ
| 问题 | 回答 |
|---|---|
| 工作坊需要多长时间？ | 一次 BC 约 2.5 小时完整 6 步。中型项目总周期约 2 周。 |
| 没有正式领域专家怎么办？ | 从业务人员/产品经理/有领域经验的高级开发中选择。 |
| 线上和线下哪个更好？ | 线下（实体白板）互动感最强，线上（Miro）可异步协作。 |
| 需要多少参与者？ | 最小 3 人（领域专家+开发+产品），最优 6-8 人。 |
| 产出物如何使用？ | 作为 ddd-domain-designer 的输入，进入聚合详细设计和代码落地。 |
| 一个工作坊能覆盖多大范围？ | 推荐一个 BC 一次。复杂领域可按子域拆分多个工作坊。 |
| 主持人必须是 DDD 专家吗？ | 不需要精通 DDD，但需要理解 6 步流程和颜色规范，具备引导能力。 |
| 产出物怎么和代码对应？ | 聚合候选 → domain-designer Aggregate，事件 → Domain Event 类，BC → 微服务模块。 |
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 个工作坊案例（电商订单履约、保险投保、用户中台、物流配送、金融支付）