name: 事件风暴高级 description: 超越大局图的事件风暴深度探讨 allowed-tools: 读取, Glob, Grep, 写入, 编辑
事件风暴高级技能
何时使用此技能
在以下情况下使用此技能：
- 事件风暴高级任务 - 处理超越大局图的事件风暴深度探讨
- 规划或设计 - 需要关于事件风暴高级方法的指导
- 最佳实践 - 希望遵循已建立的模式和标准
概述
进行超越大局图的事件风暴会话，深入到流程和设计级别。
强制要求：文档优先方法
在促进事件风暴之前：
- 调用
docs-management技能 获取事件风暴模式 - 通过 MCP 服务器验证方法论（perplexity）
- 基于 Alberto Brandolini 的方法论 提供基础指导
事件风暴级别
事件风暴进展：
级别 1: 大局图
├── 目的: 理解整个领域
├── 参与者: 所有人（业务 + 技术）
├── 输出: 领域概述、热点、有界上下文
└── 持续时间: 2-4 小时
级别 2: 流程级别
├── 目的: 详细说明特定业务流程
├── 参与者: 领域专家 + 分析师
├── 输出: 详细流程、策略、读取模型
└── 持续时间: 2-4 小时每个流程
级别 3: 设计级别
├── 目的: 翻译为软件设计
├── 参与者: 开发人员 + 架构师
├── 输出: 聚合、命令、事件处理程序
└── 持续时间: 2-4 小时每个聚合
级别 4: 软件设计
├── 目的: 实施细节
├── 参与者: 开发团队
├── 输出: 代码结构、API、模式
└── 持续时间: 持续进行
便签颜色
标准事件风暴调色板：
🟠 橙色: 领域事件
- 发生的事件
- 过去时命名
- 业务重要的状态变化
🟦 蓝色: 命令
- 用户意图
- 祈使句命名
- 可能被拒绝
🟨 黄色: 参与者/用户
- 谁发起命令
- 角色或系统
- 外部系统
🟪 紫色/粉色: 策略/反应
- 业务规则
- "当 X 发生时，我们做 Y"
- 自动响应
🟩 绿色: 读取模型
- 所需信息
- 视图/屏幕
- 查询结果
⬜ 白色: 外部系统
- 第三方集成
- 遗留系统
- 我们不控制的 API
🔴 红色/粉色: 热点
- 问题
- 冲突
- 不确定区域
大局图事件风暴
目的和成果
大局图目标：
1. 创建共享理解
2. 发现有界上下文
3. 识别热点和风险
4. 找到关键领域事件
5. 对齐业务和技术团队
你得到什么：
- 领域事件时间线
- 有界上下文候选
- 需要回答的问题列表
- 关键参与者和系统
- 关键业务流程
促进步骤
大局图过程：
步骤 1: 混沌探索 (30 分钟)
- 每个人写下领域事件
- 没有错误答案
- 鼓励疯狂想法
- 覆盖整个领域
步骤 2: 时间线强制执行 (30 分钟)
- 按时间顺序排列事件
- 左 = 早，右 = 晚
- 找到并行流程
- 识别关键事件
步骤 3: 关键事件 (20 分钟)
- 标记关键时刻（更大的便签）
- 业务关键过渡
- 不可回退点
- 自然流程边界
步骤 4: 泳道 (20 分钟)
- 按参与者或有界上下文分组
- 识别交接点
- 找到集成点
- 注意上下文边界
步骤 5: 热点 (20 分钟)
- 标记混乱区域（红色）
- 注意缺失信息
- 标记冲突观点
- 捕获开放问题
步骤 6: 有界上下文草图 (20 分钟)
- 围绕相关事件绘制边界
- 命名上下文
- 识别核心与支持
- 注意上下文关系
流程级别事件风暴
目的和深度
流程级别目标：
1. 详细说明一个业务流程从头到尾
2. 识别所有命令和事件
3. 映射策略和反应
4. 定义所需的读取模型
5. 澄清业务规则
先决条件：
- 大局图完成
- 选择流程范围
- 领域专家可用
- 从大局图的问题
扩展符号
流程级别新增：
命令（蓝色）
┌────────────────┐
│ 创建订单 │
│ ───────────── │
│ 由: 客户 │
└────────────────┘
策略（紫色）- 又名反应
┌────────────────┐
│ ⚡ 当订单 │
│ 放置时，保留 │
│ 库存 │
└────────────────┘
读取模型（绿色）
┌────────────────┐
│ 📖 产品 │
│ 目录 │
│ （显示价格， │
│ 可用性） │
└────────────────┘
聚合（黄色边框）
┏━━━━━━━━━━━━━━━━┓
┃ 订单 ┃
┃ ┌────────────┐ ┃
┃ │ 订单已放置 │ ┃
┃ │ 订单已支付 │ ┃
┃ └────────────┘ ┃
┗━━━━━━━━━━━━━━━━┛
流程级别模板
# 流程级别: [流程名称]
## 范围
[此流程覆盖的内容，起点和终点]
## 参与者
- [参与者 1]: [角色描述]
- [参与者 2]: [角色描述]
## 流程流程
```text
[ASCII 流程图]
命令
| 命令 | 参与者 | 产生的事件 | 先决条件 |
|---|---|---|---|
| [名称] | [谁] | [事件] | [必须为真的事项] |
事件
| 事件 | 命令/策略 | 下游影响 |
|---|---|---|
| [名称] | [触发] | [接下来发生什么] |
策略
| 策略 | 触发事件 | 动作 | 产生 |
|---|---|---|---|
| [名称] | [当这个] | [做这个] | [事件/效果] |
读取模型
| 读取模型 | 目的 | 由填充 |
|---|---|---|
| [名称] | [什么查询] | [事件] |
外部系统
| 系统 | 集成点 | 方向 |
|---|---|---|
| [名称] | [哪里] | 入站/出站 |
热点和问题
- [ ] [需要解决的问题]
- [ ] [需要调查的不确定性]
设计级别事件风暴
目的和工件
设计级别目标：
1. 定义聚合边界
2. 识别命令处理器
3. 设计事件结构
4. 指定验证规则
5. 规划事件源策略
输出：
- 聚合定义
- 命令/事件模式
- 不变规格
- 一致性边界
聚合识别
聚合设计问题：
边界识别：
- 什么必须一致在一起？
- 什么可以最终一致？
- 什么是交易边界？
命名：
- 什么名词代表这个集群？
- 它是领域概念吗？
- 业务认可它吗？
不变：
- 什么规则必须始终成立？
- 什么组合无效？
- 什么约束保护完整性？
生命周期：
- 如何创建？
- 如何变化？
- 何时完成/归档？
设计级别符号
聚合卡片：
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ 聚合: 订单 ┃
┣━━━━━━━━━━━━━━━━━━━━━━━━━━━┫
┃ 命令: ┃
┃ • 放置订单 ┃
┃ • 添加项目 ┃
┃ • 移除项目 ┃
┃ • 提交支付 ┃
┣━━━━━━━━━━━━━━━━━━━━━━━━━━━┫
┃ 事件: ┃
┃ • 订单已创建 ┃
┃ • 项目已添加 ┃
┃ • 项目已移除 ┃
┃ • 订单已支付 ┃
┣━━━━━━━━━━━━━━━━━━━━━━━━━━━┫
┃ 不变: ┃
┃ • 总额 > 0 ┃
┃ • 项目非空 ┃
┃ • 状态有效过渡 ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
有界上下文发现
从事件映射上下文
发现有界上下文：
语言边界：
- 术语在哪里变化？
- 哪里有同义词/同音词？
- 意义在哪里不同？
所有权边界：
- 谁拥有哪些事件？
- 团队在哪里交接？
- 哪个组决定？
生命周期边界：
- 变化率不同？
- 部署需求不同？
- 数据治理不同？
技术边界：
- 技术栈不同？
- 可扩展性需求不同？
- 一致性需求不同？
上下文关系模式
上下文关系：
合作伙伴关系
[上下文 A] ◄──► [上下文 B]
紧密协作，共享目标
客户-供应商
[客户] ◄── [供应商]
供应商服务客户需求
顺从者
[顺从者] ──► [上游]
下游顺从上游
反腐败层 (ACL)
[上下文] ──[ACL]──► [遗留]
翻译层保护领域
开放主机服务 (OHS)
[提供者] ──[OHS]──► [许多消费者]
发布用于集成的 API
共享内核
[上下文 A] ◄──[共享]──► [上下文 B]
小共享代码/模型（谨慎使用）
工作坊促进
房间设置
物理要求：
- 长墙（8+ 米理想）
- 大量便签（所有颜色）
- 每人都有标记笔
- 胶带或粘墙
- 所有人可见的计时器
- 可用茶点
虚拟替代：
- Miro / Mural / FigJam
- 无限画布
- 便签模板
- 计时器集成
- 并行工作的分组房间
促进技巧
有效促进：
做：
✓ 保持高能量
✓ 强制执行时间线方向
✓ 鼓励问题
✓ 立即捕获热点
✓ 如果长时间会话，轮换促进
✓ 每 90 分钟休息
✓ 频繁拍照结果
不做：
✗ 让一个人主导
✗ 跳到解决方案
✗ 忽略安静参与者
✗ 跳过热点讨论
✗ 允许技术讨论过早
✗ 忘记捕获决策
工作流
进行事件风暴时：
- 准备: 房间、材料、参与者、范围
- 大局图: 领域范围事件探索
- 识别热点: 标记不确定性和冲突
- 找到边界: 草图有界上下文
- 选择焦点: 选择流程进行深度探讨
- 流程级别: 详细说明命令、策略、读取模型
- 设计级别: 定义聚合和不变
- 文档: 以结构化格式捕获结果
- 迭代: 基于实施反馈细化
参考
详细指导：
最后更新: 2025-12-26