ForceInjection DDD Context Map
🌐 English version: English
使用时机
- 限界上下文已定义完毕，需要设计它们之间的协作与集成关系。
- 需要明确"谁依赖谁、用什么模式集成、契约谁负责"。
ddd-model-review报告"集成模式与映射不一致"时，作为回溯目标重新执行。
输入要求
- 必需：上下文目录（来自
ddd-contexts）、事件流热点标注中的跨边界点（来自ddd-discover）。 - 可选：子域分类表（来自
ddd-subdomains，用于理解上下文的业务权重）、现有接口/消息/数据交换方式、团队协作模式。
流程
- 列举关系：列出所有上下文对（pair），标注依赖方向与数据/事件流向。
- 选择模式：为每对关系选择集成模式——ACL (Anti-Corruption Layer)、OHS (Open Host Service)、PL (Published Language)、Shared Kernel、Conformist、Customer-Supplier——并说明选择理由。
- 定义翻译：明确输入翻译、输出翻译、语义差异处理、字段映射规则。
- 契约所有权：明确每个契约的 Owner、消费者、变更流程、发布策略。
- 失败模式分析：针对每个集成点分析超时、降级、幂等、重试、补偿、数据延迟等失败模式。
- 版本策略：定义兼容窗口、弃用策略、契约测试要求、发布节奏。
输出
| 工件 | 结构要求 |
|---|---|
| 上下文关系矩阵 | 表格：上游、下游、模式、数据/事件、风险 |
| 契约所有权矩阵 | 表格：契约、Owner、消费者、变更流程、发布策略 |
| 翻译与 ACL 决策 | 表格：对象/事件、翻译规则、语义差异说明、实现位置 |
| 失败模式与缓解 | 表格：失败模式、影响、检测方式、缓解措施、补偿策略 |
| 版本策略 | 列表：版本命名规则、兼容窗口、弃用策略、契约测试要求 |
校验清单
- 所有跨上下文交互都有显式的模式与所有权
- 核心域的输入受 ACL 或等效翻译边界保护
- 至少识别 5 个失败模式并给出可执行的缓解措施
- 无循环依赖（若存在需标注为风险并给出解耦方案）
- 版本策略覆盖向后兼容窗口与弃用流程
回溯触发
- 检测到循环依赖，或单一上下文承担 > 3 个上游关系 → 回溯至
ddd-subdomains或ddd-contexts（可能存在"上帝上下文"或子域误分）。 - 被
ddd-model-review触发：战术层发现了新的集成需求，与当前映射不一致。
示例
@ddd-context-map
基于以下上下文目录，帮我设计上下文间的集成关系：
- Booking（预订全生命周期）
- Room Catalog（会议室资源管理）
- Identity（用户认证与授权）
请输出关系矩阵、集成模式选择、契约所有权与失败模式分析。