ddd-contexts

name	ddd-contexts
description	设计限界上下文及其通用语言：边界、职责、词汇表、团队所有权与边界 ADR。
risk	safe
source	self
tags	[ddd, strategic, bounded-context, ubiquitous-language]
date_added	2026-05-08

DDD Contexts

🌐 English version: English

使用时机

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

输入要求

• 必需：子域分类表与核心域声明（来自 ddd-subdomains）、事件流与热点标注（来自 ddd-discover）。
• 可选：组织信息（团队边界、交付节奏）、术语种子（来自 ddd-scope）。

流程

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%。

示例

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