ddd-scope v1.1.0A

Immutable. This exact content never changes and is served at /api/v1/blob/efa3a121dce356ee.

---
name: ddd-scope
description: >-
  DDD scope: converge vague requirements into executable DDD modeling inputs — problem
  statement, goals/non-goals, constraints, term seeds, and risk list. Use when converging
  fuzzy requirements into DDD modeling inputs or defining modeling scope.
risk: safe
source: self
tags: "[ddd, discovery, scope]"
date_added: "2026-05-08"
slug: ddd-scope
version: 1.1.0
displayName: ddd-scope
---

# DDD Scope

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

## 使用时机

- 需求描述模糊，不同角色对问题边界理解不一致。
- 全新项目启动前，需要锁定建模范围、约束与关键风险。
- 后续 Skill 报告"业务价值主张不清晰"时，作为回溯目标重新执行。

## 输入要求

- **必需**：业务目标或问题描述（允许非结构化文本：口述、PRD 片段、工单描述均可）。
- **可选**：当前系统形态、关键参与方、外部系统依赖、已知约束（时间/合规/性能/团队）。

**输入缺失/不可用时的可观察出口**：若描述为空、或内容与业务无关（如纯技术配置、无业务意图的报错日志），**不要**硬收敛。输出一段补齐请求：引用收到的原文，写明"缺少业务目标或问题描述"，并给一个填空模板（"我们在 <场景> 遇到 <痛点>，期望 <结果>"），然后停下等待。收到可用的描述后从头重跑流程。

**NOT for（不适用，转交对应技能）**：

- 已有清晰需求、要直接做领域发现（事件风暴） → `ddd-discover`。
- 已有事件流、要做子域切分 → `ddd-subdomains`。
- 已明确子域、要划分上下文 → `ddd-contexts`。
- 本技能只收敛建模输入，不产出任何代码或技术方案。

## 流程

1. 提取业务意图，形成 1 句**问题陈述**（描述痛点）和 1 句**价值陈述**（描述期望结果）。
2. 明确**目标**与**非目标**，建立范围边界——显式声明"不做什么"。
3. 列出**约束与假设**，每条标注"可验证 / 不可验证"及验证方式。
4. 生成**术语种子清单**：从描述中提取名词、动词、状态词，标注歧义点与所属场景。
5. 识别**风险清单**：覆盖业务风险、集成风险、数据一致性风险、交付风险，给出初步缓解建议。
6. 输出**下一步准备清单**：进入 `ddd-discover` 所需的最小信息、参与角色与期望产出。

## 输出

| 工件               | 结构要求                               |
| :----------------- | :------------------------------------- |
| 问题陈述与价值陈述 | 各 1 句，可被业务方认可                |
| 目标 / 非目标      | 列表化，每条包含边界解释               |
| 约束与假设         | 表格：约束/假设、可验证性、验证方式    |
| 术语种子清单       | 表格：术语、定义候选、歧义点、所属场景 |
| 风险清单           | 表格：风险、影响、触发条件、缓解建议   |
| 下一步准备清单     | 列表：角色、必要输入、期望产出         |

## 校验清单

- [ ] 目标与非目标互斥且可落地执行
- [ ] 约束与假设均已标注验证方式
- [ ] 术语种子 ≥ 10 个，歧义点已标注（豁免：极小范围的一次性工具类建模，术语天然不足 10 个——写明豁免理由与实际数量，其余四项校验不得豁免）
- [ ] 风险清单覆盖业务 / 集成 / 一致性 / 交付四类
- [ ] 问题陈述与价值陈述不含技术实现细节

## 回溯触发

本 Skill 为体系入口，不触发回溯。但以下情况会被下游触发回溯至此：

- `ddd-subdomains` 无法区分核心域与支撑域 → 业务价值主张不清晰，需重新收敛 scope。

## 示例

### 调用示例

```text
@ddd-scope
业务描述：我们的订单售后流程非常混乱，跨系统协同困难，客户投诉响应慢。
请帮我收敛为 DDD 建模输入：输出问题陈述、目标/非目标、约束与假设、术语种子、风险清单。
```

### 最短真实示例（前置 → 调用 → 产出摘录）

前置：只需一段业务描述（口述、PRD 片段均可），无其他工件依赖。

调用：

```text
@ddd-scope
业务描述：我们的会员积分总是对不上账，客服手动调分，运营想上积分商城但没人敢保证分数正确。
```

产出摘录（应长这样）：

```text
问题陈述：积分账实不一致，人工调分不可审计。
价值陈述：积分变动全程可追溯，支撑积分商城上线。
目标：积分入账/扣减/过期规则统一建模。
非目标：不改造支付通道；不做商城前端。
术语种子（摘录）：积分（=营销积分还是抵扣券？歧义）、调分、入账、过期 …
风险清单（摘录）：双系统并行期分数漂移（一致性风险）→ 缓解：以积分账本为唯一真源。
```

### 另一场景（全新内部平台）

同一技能，输入换成"我们要给 20 家门店做统一排班，现在各店用 Excel"——产出结构相同，但术语种子会集中在"班次/工时/替班"等排班域词汇，且非目标里应显式排除"考勤硬件对接"。业务场景不同不影响流程六步，只影响术语种子与风险清单的内容。

## 常见错法 → 改法

| 错法 | 改法 |
| :--- | :--- |
| 描述里没业务意图（纯报错日志/配置）也硬收敛 | 停在补齐请求，引用原文＋给填空模板（见"输入缺失/不可用时的可观察出口"） |
| 问题陈述写成技术方案（"引入 Kafka 解耦"） | 陈述只描述痛点与期望结果；技术细节留给后续建模技能 |
| 非目标空着或写"无" | 显式排除至少一条易蔓延项（"不做 X"），否则范围边界不可校验 |
| 术语种子不足 10 个就默默过关 | 按校验清单新规：写明豁免理由与实际数量，或追问更多场景描述补齐 |
| 约束全部标"不可验证" | 逐条追问可验证性；确实不可验证的保留标注，但须给出触发重估的条件 |
| 用户没要求就自动跑 scope 收敛 | 本技能仅在用户点名或下游技能（`ddd-subdomains`）回溯触发时执行，不自主触发 |
| scope 定稿后下游发现价值主张不清却原地重跑 | 允许回溯重跑，但须在输出中注明"第 N 次收敛"及本轮变更点，避免无限循环 |