ddd-contexts v1.1.0A

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

---
name: ddd-contexts
description: "Design bounded contexts and their ubiquitous language: boundaries, responsibilities, glossary, team ownership, and boundary ADRs. Use when defining bounded contexts."
risk: safe
source: self
tags: "[ddd, strategic, bounded-context, ubiquitous-language]"
date_added: "2026-05-08"
slug: ddd-contexts
version: 1.1.0
displayName: ddd-contexts
---

# DDD Contexts

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

## 使用时机

- 子域已分类，需要设计解决方案空间的限界上下文边界。
- 需要为每个上下文建立统一语言（Ubiquitous Language），消除术语歧义。
- `ddd-aggregates` 报告"不变量跨越多个上下文"，或 `ddd-model-review` 报告"术语冲突率 > 20%"时，作为回溯目标重新执行。

## 输入要求

- **必需**：子域分类表与核心域声明（来自 `ddd-subdomains`）、事件流与热点标注（来自 `ddd-discover`）。
- **可选**：组织信息（团队边界、交付节奏）、术语种子（来自 `ddd-scope`）。
- **输入不完整时的处置**：缺子域分类或事件流 → 一行指明缺什么，并指向产出它的技能（"缺子域分类表——先跑 `ddd-subdomains`，或直接粘贴你的子域清单"）；用户坚持只给口头描述时 → 按描述聚类，但把每个上下文标 Assumption，并在输出头部列出"待补输入"。不得静默用臆测补齐必需输入。

## 流程

1. **聚类**：以一致性边界与语言边界为依据，将能力聚类为上下文候选。一个上下文内的术语必须含义唯一。
2. **定义职责**：为每个上下文明确业务职责、核心概念、主要事件与数据所有权。
3. **建立语言**：为上下文内每个核心术语建立定义（含 1 个业务示例），标注同义词与反术语。
4. **划定边界**：明确哪些概念仅在此上下文内有效、哪些概念跨上下文时必须翻译。
5. **所有权与 ADR**：指定负责团队、决策者、契约 Owner；输出边界决策的 ADR（含理由、权衡、风险、备选方案）。
6. **冲突处理**：处理跨上下文的同名不同义术语——给出翻译策略或重命名建议。

## 输出

| 工件           | 结构要求                                                         |
| :------------- | :--------------------------------------------------------------- |
| 上下文目录     | 表格：上下文名、职责、核心术语、主要事件、数据所有权、负责团队   |
| 通用语言词汇表 | 表格：术语、定义、业务示例、所属上下文、同义词、反术语、冲突处理 |
| 反术语清单     | 表格：禁用词、禁用原因、推荐替代                                 |
| 边界 ADR 列表  | 每条含：决策、理由、权衡、风险、备选方案                         |
| 语言演进规则   | 列表：新增/变更流程、评审角色、版本策略                          |

## 校验清单

- [ ] 每个上下文有明确的"职责"与"非职责"
- [ ] 数据所有权无冲突；跨上下文访问必须通过契约/翻译
- [ ] 每个上下文至少有 1 条显式的权衡点与风险点（ADR）
- [ ] 术语冲突已全部处理（翻译或重命名）
- [ ] 反术语清单覆盖技术词污染（Manager, Processor, Handler 等泛化词）与模糊业务词
- [ ] 若下单/交易流程中引入了"需求/意向"类中间概念（如 ShippingRequest、OrderDraft、BookingIntent），已声明其与主聚合的生命周期关系（升格为独立聚合 vs 等价为主聚合的 VO），两种选择均合法但 **必须明示并记录 ADR**

## 回溯触发

- > 5 个术语存在不可调和的跨上下文冲突 → 回溯至 `ddd-discover`，领域理解不足。
- 被 `ddd-aggregates` 触发：不变量跨越多个上下文 → 一致性需求被边界割裂，需重新划分。
- 被 `ddd-model-review` 触发：聚合边界与上下文边界矛盾，或术语冲突率 > 20%。

## 示例

```text
@ddd-contexts
基于以下子域分类和事件流，帮我设计限界上下文：
- Core: 预订与冲突管理
- Supporting: 会议室资源管理
- Generic: 用户身份与权限
[粘贴事件流表]
请输出上下文目录、通用语言词汇表、边界 ADR。
```

产出摘录（同场景，节选）：

```text
| 上下文     | 职责               | 核心术语           | 数据所有权 | 负责团队   |
| :--------- | :----------------- | :----------------- | :--------- | :--------- |
| 预订       | 创建/取消/冲突仲裁 | Booking, Conflict  | booking 表 | 预订小组   |
| 会议室资源 | 房间/容量维护      | Room, Capacity     | rooms 表   | 资源小组   |

边界 ADR-1：Booking 与 Room 分属两个上下文——预订侧只持有 room_id 引用；
跨上下文查询走"房间快照"翻译（理由：可用性规则变更频率 ≫ 房间主档；
风险：翻译滞后显示过期容量；备选：合并为单一上下文——被团队边界否决）。
```

## 常见错法 → 改法

| 错法 | 改法 |
| :--- | :--- |
| 按技术分层切上下文（"数据层/服务层/UI 层"） | 按一致性与语言边界聚类；分层不是限界上下文 |
| 一个术语在多个上下文里"含义差不多就行" | 同名不同义必须显式翻译或重命名，并记 ADR |
| 词汇表只收名词不收反术语 | 反术语清单为必产出（Manager/Handler 类泛化词、模糊业务词） |
| 边界画完不写 ADR，事后无法回答"为什么这么切" | 每个上下文至少 1 条权衡点 + 风险点（见校验清单） |
| 缺子域分类就硬聚类，输出看似完整 | 一行指明缺项，标注 Assumption（见"输入不完整时的处置"） |