Ddd Context Map

---
name: ddd-context-map
description: "Map relationships and integration strategies between bounded contexts: pattern selection, contract ownership, failure modes, and versioning strategy. Use when mapping bounded-context relationships, integration patterns, or contract ownership."
risk: safe
source: self
tags: "[ddd, strategic, context-map, integration]"
date_added: "2026-05-08"
slug: ddd-context-map
version: 1.1.0
displayName: ddd-context-map
---

# DDD Context Map

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

## 使用时机

- 限界上下文已定义完毕，需要设计它们之间的协作与集成关系。
- 需要明确"谁依赖谁、用什么模式集成、契约谁负责"。
- `ddd-model-review` 报告"集成模式与映射不一致"时，作为回溯目标重新执行。

**NOT for（边界判定，逐条可观察）**：

- 上下文目录尚不存在（`ddd-contexts` 未跑）→ 先跑 `ddd-contexts`，本技能不代划上下文边界。
- 问题在聚合内部（不变量、实体/值对象划分）→ 走 `ddd-aggregates`；本技能只管**跨**上下文关系。
- 只想看单个服务内部架构分层 → 走 `architecture-patterns`；无跨上下文集成点时本技能无输入可分析。

## 输入要求

- **必需**：上下文目录（来自 `ddd-contexts`）、事件流热点标注中的跨边界点（来自 `ddd-discover`）。
- **可选**：子域分类表（来自 `ddd-subdomains`，用于理解上下文的业务权重）、现有接口/消息/数据交换方式、团队协作模式。

## 流程

1. **列举关系**：列出所有上下文对（pair），标注依赖方向与数据/事件流向。
2. **选择模式**：为每对关系选择集成模式——ACL (Anti-Corruption Layer)、OHS (Open Host Service)、PL (Published Language)、Shared Kernel、Conformist、Customer-Supplier——并说明选择理由。
3. **定义翻译**：明确输入翻译、输出翻译、语义差异处理、字段映射规则。
4. **契约所有权**：明确每个契约的 Owner、消费者、变更流程、发布策略。
5. **失败模式分析**：针对每个集成点分析超时、降级、幂等、重试、补偿、数据延迟等失败模式。
6. **版本策略**：定义兼容窗口、弃用策略、契约测试要求、发布节奏。

## 输出

| 工件            | 结构要求                                             |
| :-------------- | :--------------------------------------------------- |
| 上下文关系矩阵  | 表格：上游、下游、模式、数据/事件、风险              |
| 契约所有权矩阵  | 表格：契约、Owner、消费者、变更流程、发布策略        |
| 翻译与 ACL 决策 | 表格：对象/事件、翻译规则、语义差异说明、实现位置    |
| 失败模式与缓解  | 表格：失败模式、影响、检测方式、缓解措施、补偿策略   |
| 版本策略        | 列表：版本命名规则、兼容窗口、弃用策略、契约测试要求 |

## 校验清单

- [ ] 所有跨上下文交互都有显式的模式与所有权
- [ ] 核心域的输入受 ACL 或等效翻译边界保护
- [ ] 至少识别 5 个失败模式并给出可执行的缓解措施
- [ ] 无循环依赖（若存在需标注为风险并给出解耦方案）
- [ ] 版本策略覆盖向后兼容窗口与弃用流程

## 回溯触发

- 检测到循环依赖，或单一上下文承担 > 3 个上游关系 → 回溯至 `ddd-subdomains` 或 `ddd-contexts`（可能存在"上帝上下文"或子域误分）。
- 被 `ddd-model-review` 触发：战术层发现了新的集成需求，与当前映射不一致。

## 示例

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

前置：`ddd-contexts` 已产出上下文目录（3 个上下文）。

调用：

```text
@ddd-context-map
基于以下上下文目录，帮我设计上下文间的集成关系：
- Booking（预订全生命周期）
- Room Catalog（会议室资源管理）
- Identity（用户认证与授权）
请输出关系矩阵、集成模式选择、契约所有权与失败模式分析。
```

产出摘录（关系矩阵节选，演示"长什么样"）：

```text
| 上游          | 下游    | 模式              | 数据/事件        | 风险                 |
|---------------|---------|-------------------|------------------|----------------------|
| Room Catalog  | Booking | OHS + PL          | RoomCapacity 事件| 目录 schema 变更     |
| Identity      | Booking | ACL               | UserRef 翻译     | 身份模型语义漂移     |
| Booking       | Booking | Customer-Supplier | 预订策略协商      | 循环依赖（见回溯触发）|
```

### 示例 2 · 前置失败时的出口

调用时若上下文目录缺失，**不猜测上下文**，按失败闭集处理：

```text
@ddd-context-map  # 附带内容为空
```

→ 出口：显式回复「缺少上下文目录（必需输入来自 ddd-contexts）」，列出缺失项，停止；不产出任何矩阵（空输入产出的矩阵必为编造）。

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

| 情形 | 可观察出口 |
|------|-----------|
| 无上下文目录（必需输入缺失） | 停止并指出缺失项；**不产出**任何矩阵 |
| 上下文目录与本仓项目不符（错仓型：目录来自另一项目） | 停止并指出「上下文目录与当前仓库/项目不匹配」，列出冲突证据（术语对不上） |
| 无网/无仓环境 | 仍可基于用户粘贴的目录离线分析；产出中显式标注「未经仓库交叉验证」 |
| 关系对数量为 0 | 回复「无跨上下文交互点」，不产出空表；提示可能边界已合并 |
| 出现循环依赖 | 不静默接受：标注为风险并给出解耦方案，同时触发「回溯触发」节 |

## 错法 → 改法（FAQ）

| 错法 | 后果 | 改法 |
|------|------|------|
| 不选模式，只画"服务 A 调服务 B"箭头 | 契约所有权悬空，变更即碎 | 每对关系必须落到六模式之一并写理由 |
| 用共享数据库当集成模式 | 上游 schema 一改下游全崩 | 改为 OHS+PL 或 ACL；共享库只允许在 Shared Kernel 且有联合所有权时出现 |
| 核心域直接 Conformist 到通用域模型 | 核心域被外部模型腐蚀 | 核心域输入一律 ACL 或等效翻译边界（见校验清单） |
| 失败模式只写"加个重试" | 幂等缺失导致重复消费 | 每个集成点覆盖超时/降级/幂等/重试/补偿/数据延迟，缓解措施要可执行 |
| 凭感觉划分 Owner | 变更流程无人拍板 | 契约所有权矩阵中 Owner 填具体团队/角色，不填"后端" |
| 自主触发（无用户请求自行跑映射） | 与本仓技能调用纪律冲突 | 本技能仅在用户显式调用或 `ddd-model-review` 回溯触发时执行，不自主触发 |