---
name: ddd-discover
description: >-
  Collaborative domain discovery via event storming, producing event streams,
  command/event candidates, hotspots, ambiguity lists, and preliminary
  context-boundary clues for downstream subdomain classification. Use when doing
  domain discovery — identifying domain events and commands, aligning core business
  flows and exception paths, or re-running discovery after bounded-context term
  conflicts. NOT for: facilitating live EventStorming workshops (formats and
  facilitation patterns are separate reference material), designing aggregate
  boundaries, or partitioning/classifying subdomains — deliverables, not facilitation.
risk: safe
source: self
tags: "[ddd, discovery, event-storming]"
date_added: "2026-05-08"
slug: ddd-discover
version: 1.1.0
displayName: ddd-discover
---

# DDD Discover

> English version: [English](SKILL.en.md)

## 使用时机

- 需要快速对齐核心业务流程与领域边界线索。
- 需求已明确（来自 `ddd-scope` 或用户直接提供），需要探索领域内部发生了什么。
- `ddd-contexts` 报告"术语冲突不可调和"时，作为回溯目标重新执行。

## 输入要求

- **必需**：业务场景描述（用户故事、PRD、工单、或 `ddd-scope` 的输出均可）。
- **可选**：关键参与方与外部系统、业务约束与非目标（来自 `ddd-scope`）。

## 流程

1. **列举事件**：以"已发生的事实"为视角，用**过去时**命名领域事件（如 OrderPlaced, PaymentReceived）。
2. **补全命令**：为每个事件补充触发它的命令、发起者、关键输入数据。
3. **排列时序**：将事件按时间线组织，识别分支、回滚、异常路径（至少覆盖 1 条主路径 + 2 条异常路径）。
4. **标注热点**：标记高频事件、强一致性点、跨系统边界、性能敏感点、合规检查点。
5. **生成歧义清单**：记录术语冲突、状态不明确、职责归属模糊的问题，标注"谁必须确认"。
6. **输出边界线索**：从事件聚类与热点分布中提取初步的能力分组与上下文边界候选。

## 输出

| 工件         | 结构要求                                                            |
| :----------- | :------------------------------------------------------------------ |
| 事件流表     | 表格：序号、事件名（过去时）、触发命令、参与者、输入/输出、异常分支 |
| 命令候选清单 | 表格：命令、发起者、期望结果、幂等性要求                            |
| 事件候选清单 | 表格：事件、关键字段、是否跨上下文、是否对外发布                    |
| 热点标注     | 列表：一致性热点、集成热点、性能热点、合规热点                      |
| 歧义清单     | 表格：歧义点、影响范围、需确认方、建议决策                          |
| 边界线索     | 列表：初步能力分组与潜在上下文边界                                  |

## 校验清单

- [ ] 事件使用过去时命名，业务可理解
- [ ] 至少覆盖 1 条主路径 + 2 条异常/回滚路径
- [ ] 热点中明确标注了跨系统边界与强一致性点
- [ ] 歧义清单中每条都标注了"谁必须确认"
- [ ] 边界线索可被 `ddd-subdomains` 直接消费

## 回溯触发

- 本 Skill 被 `ddd-contexts` 触发回溯：当 > 5 个术语存在不可调和的跨上下文冲突时，说明领域理解不足，需重新发现。

## 示例

```text
@ddd-discover
基于以下 scope 输出，帮我做领域发现：
- 问题：订单售后流程混乱
- 目标：支持退款、换货、投诉处理
- 非目标：不涉及正向下单流程
请输出事件流表、命令/事件候选、热点标注与歧义清单。
```

### 第二个示例（含产出摘录）

**前置**：`ddd-scope` 已产出范围（问题/目标/非目标），或用户直接给了一段业务描述；无既成事件清单。

**调用句**：

```text
「对工单系统做领域发现：用户提交工单 → 客服分派 → 工程师处理 → 用户评价。
重点关心超时未响应和跨部门转派的场景。」
```

**产出摘录**（事件流表节选——完整输出含全部 6 类工件）：

```markdown
## 事件流表（节选）
| 序号 | 事件名 | 触发命令 | 参与者 | 异常分支 |
|------|--------|---------|--------|---------|
| 1 | TicketSubmitted | SubmitTicket | 用户 | 附件超限 → TicketRejected |
| 2 | TicketAssigned | AssignTicket | 客服主管 | 无人可派 → AssignmentEscalated |
| 3 | TicketResolved | ResolveTicket | 工程师 | 跨部门转派 → TicketTransferred |

## 热点标注
- 强一致性点：TicketAssigned（重复分派防护）
- 集成热点：TicketTransferred（跨部门 = 跨上下文边界线索）

## 歧义清单（节选）
| 歧义点 | 需确认方 |
|--------|---------|
| 「转派后 SLA 是否重置」 | 客服负责人 |
```

反例对照：只回一段「这个系统包含工单、客服、工程师……」的叙述散文、无表格无清单 → 不合格（六类工件缺一即视为未完成输出）。

## 失败出口与边界处置（可观察）

| 情形 | 可观察出口 |
|------|-----------|
| 无必需输入（用户没给业务场景、也没有 `ddd-scope` 输出） | 停下向用户要「业务场景描述（用户故事/PRD/工单任一）」；**不**凭空编造事件流 |
| 输入只有一句话（信息量不足） | 先输出「假设 + 歧义清单」并标「待确认」，继续产出初版六件套；假设不得伪装成事实 |
| 用户要求现场引导 EventStorming 工作坊 | 不在范围（description NOT for），说明后停；不冒充工作坊引导 |
| 用户直接要聚合边界或子域分类 | 指向 `ddd-aggregates` / `ddd-subdomains`，本件只产出**线索** |
| `ddd-contexts` 回溯触发时拿不到冲突清单 | 向用户索取冲突术语列表（>5 个不可调和冲突才算触发条件）；列不出则不回溯 |

## 错法 → 改法

| 错法 | 改法 |
|------|------|
| 事件用现在时命名（如 SubmitOrder） | 一律过去时（OrderSubmitted）——事件是「已发生的事实」 |
| 只写主路径，不写异常分支 | 至少 1 主 + 2 异常/回滚路径（校验清单硬项） |
| 事件流水准直接当限界上下文边界 | 边界线索只是候选，交给 `ddd-subdomains` 分类后再定 |
| 歧义不标确认人，写完就丢 | 每条歧义标「谁必须确认」，否则下游无法收敛 |
| 模型自主对大改动直接跑发现 | 本件面向用户显式请求；发现结论影响领域模型，须人在环确认歧义清单 |
| 输出散文叙述代替六类工件 | 六类工件（表格/清单）齐全才算完成——结构要求见「输出」节 |