name: context-mapping description: 使用DDD上下文映射模式映射有界上下文之间的关系。用于定义上游/下游关系、集成策略（ACL、OHS、PL）或生成Context Mapper DSL输出。遵循事件风暴进行有界上下文发现。 argument-hint: [有界上下文文件] [–mode full|quick|guided] [–output cml|diagram|both] [–input-dir <路径>] [–dir <路径>] allowed-tools: Read, Write, Glob, Grep, Skill, Task, AskUserQuestion

上下文映射技能

交互式映射配置

使用AskUserQuestion配置上下文映射会话：

# 问题1：映射模式（MCP：DDD上下文映射方法论）
question: "您需要什么级别的上下文映射分析？"
header: "模式"
options:
  - label: "完整分析（推荐）"
    description: "系统分析所有有界上下文并生成CML输出"
  - label: "快速概览"
    description: "仅识别明显关系（约3K令牌）"
  - label: "引导发现"
    description: "交互式，确认每个关系与用户"
  - label: "模式聚焦"
    description: "专注于特定集成模式（ACL、OHS等）"

# 问题2：关系清晰度（MCP：DDD上游/下游模式）
question: "上下文边界有多清晰？"
header: "清晰度"
options:
  - label: "定义良好"
    description: "有界上下文已识别，需要关系映射"
  - label: "部分已知"
    description: "一些上下文已识别，可能发现更多"
  - label: "探索性"
    description: "从零开始，发现上下文和关系"
  - label: "来自事件风暴"
    description: "使用先前事件风暴会话的输出"

使用这些响应选择适当的映射模式并校准发现深度。

使用领域驱动设计上下文映射模式映射有界上下文之间的关系。生成Context Mapper DSL（CML）输出和集成策略建议。

何时使用此技能

关键词： 上下文映射、有界上下文、上游、下游、ACL、防腐败层、共享内核、客户供应商、开放主机服务、发布语言、顺从者、合作伙伴关系、CML、集成模式、领域关系

在以下情况下使用此技能：

事件风暴后，当有界上下文已识别时
定义领域之间的集成策略
记录领域关系和依赖
生成上下文映射图（Mermaid/PlantUML）
创建Context Mapper DSL（CML）输出
基于上下文关系规划团队边界
识别需要防腐败层的地方

上下文映射模式

八种战略DDD模式用于定义上下文关系：

对称模式（平等关系）

模式	缩写	描述	使用时机
共享内核	SK	上下文间共享代码/模型	两个上下文需要相同的领域逻辑
合作伙伴关系	P	平等协作，相互依赖	团队共同演进，无明确上游/下游

非对称模式（上游/下游）

模式	缩写	描述	使用时机
客户/供应商	C/S	上游供应，下游消费	清晰的提供者/消费者关系
顺从者	CF	下游采用上游模型	下游团队无影响力谈判
防腐败层	ACL	下游翻译上游模型	上游模型不适合下游需求
开放主机服务	OHS	上游提供正式API	多个消费者需要标准化访问
发布语言	PL	标准化API格式（OpenAPI等）	跨团队通信需要合同

无集成

模式	缩写	描述	使用时机
分离方式	SW	无集成，独立演进	上下文之间无有意义关系

详细模式描述与示例： 参见references/pattern-catalog.md

模式选择指南

决策流程

上下文是否共享代码或数据模型？
├── 是 → 共享内核 [SK]
└── 否 → 是否存在清晰的数据/服务流？
    ├── 否 → 团队是否平等协作？
    │   ├── 是 → 合作伙伴关系 [P]
    │   └── 否 → 分离方式 [SW]
    └── 是 → 识别上游（提供者）和下游（消费者）
        └── 下游能否影响上游的模型？
            ├── 否 → 上游模型是否适合下游需求？
            │   ├── 是 → 顺从者 [CF]
            │   └── 否 → 防腐败层 [ACL]
            └── 是 → 客户/供应商 [C/S]
                └── 上游是否服务多个消费者？
                    ├── 是 → 添加开放主机服务 [OHS]
                    │   └── 需要合同？ → 添加发布语言 [PL]
                    └── 否 → 基本C/S足够

详细选择标准： 参见references/pattern-selection.md

Context Mapper DSL（CML）

基本语法

ContextMap <地图名称> {
    contains <上下文1>
    contains <上下文2>

    // 非对称：下游 [D] <- 上游 [U]
    <下游上下文> [D,<模式>]<-[U,<模式>] <上游上下文>

    // 对称：双方平等
    <上下文1> [<模式>]<->[<模式>] <上下文2>
}

符号参考

符号	含义
`[D]`	下游上下文
`[U]`	上游上下文
`<-`	非对称关系（上游到下游）
`<->`	对称关系
`[D,C]`	下游 + 客户
`[U,S]`	上游 + 供应商
`[D,ACL]`	下游带防腐败层
`[U,OHS,PL]`	上游带开放主机服务 + 发布语言
`[SK]`	共享内核（对称）
`[P]`	合作伙伴关系（对称）
`[CF]`	顺从者

完整CML语法： 参见references/cml-syntax.md

多模式执行

模式选择

模式	描述	使用时机
`full`	系统分析所有有界上下文	综合映射，较大领域
`quick`	仅识别明显关系	快速概览，小领域
`guided`	交互式，确认每个关系	学习、验证、不确定关系

完整模式协议

清单 - 列出所有有界上下文及其聚合
依赖扫描 - 识别数据流和服务调用
模式分配 - 系统应用选择标准
CML生成 - 产生完整上下文地图
图生成 - 创建视觉表示
审查输出 - 标记不确定关系供人工审查

快速模式协议

上下文列表 - 枚举已知有界上下文
明显关系 - 映射清晰的上游/下游对
基本CML - 生成最小上下文地图
跳过模糊 - 标记不确定关系后续处理

引导模式协议

呈现上下文对 - 向用户展示两个上下文
询问关系 - “这些上下文是否交互？”
确定方向 - “哪个提供数据/服务？”
选择模式 - 呈现模式选项与解释
确认 - 验证用户同意分类
重复 - 继续所有上下文对

输出工件

1. Context Mapper DSL（CML）文件

/* 上下文地图：<领域名称>
 * 生成：<日期>
 * 来源：事件风暴会话
 */

ContextMap <领域名称>Map {
    contains <上下文1>
    contains <上下文2>
    // ... 关系
}

2. Mermaid图

graph LR
    subgraph "核心领域"
        A[上下文1]
    end
    subgraph "支持"
        B[上下文2]
    end
    A -->|模式| B

3. 集成策略报告

## 集成策略

### <上下文1> -> <上下文2>
- **模式：** 客户/供应商
- **方向：** 上下文1（上游）供应上下文2（下游）
- **理由：** <为何选择此模式>
- **实施：** <技术方法>
- **团队影响：** <组织考虑>

4. 团队拓扑建议

基于上下文关系，建议团队边界遵循Team Topologies模式（流对齐、平台、启用、复杂子系统）。

团队拓扑指导： 参见references/team-topologies.md

与事件风暴集成

事件风暴输入

上下文映射消耗：

有界上下文 - 命名领域边界与主要聚合
领域事件 - 跨上下文边界的事件
命令 - 触发跨上下文通信的操作
参与者 - 与多个上下文交互的用户/系统

工作流集成

领域故事讲述
    ↓（理解业务流程）
事件风暴
    ↓（发现有界上下文）
上下文映射 ← 您在这里
    ↓（定义关系）
模块化架构
    ↓（实施结构）
适应度函数
    （强制执行边界）

跨上下文事件识别

映射上下文时，识别：

跨边界事件 - 表示集成需求
共享聚合 - 潜在的共享内核候选
翻译需求 - ACL候选
API合同 - OHS/PL候选

集成策略

对于每个模式，有推荐的技术实施：

模式	实施策略
共享内核	共享NuGet包、公共项目引用
客户/供应商	内部API、MediatR通知
防腐败层	适配器模式、翻译服务
开放主机服务	REST API、gRPC服务
发布语言	OpenAPI规范、Protobuf定义
合作伙伴关系	共享事件总线、双边合同
顺从者	直接模型采用、无翻译
分离方式	无需集成代码

详细实施指导： 参见references/integration-strategies.md

示例输出

电子商务领域上下文地图

/* 上下文地图：电子商务平台
 * 生成：2025-01-15
 * 来自事件风暴会话的有界上下文
 */

ContextMap ECommercePlatform {
    contains OrderContext
    contains InventoryContext
    contains PaymentContext
    contains ShippingContext
    contains CustomerContext

    /* 订单消耗库存可用性
     * 库存拥有库存真相，订单查询它
     */
    OrderContext [D,C]<-[U,S] InventoryContext

    /* 支付隔离外部网关
     * 网关有外部模型，需要翻译
     */
    PaymentContext [D,ACL]<-[U,OHS,PL] ExternalPaymentGateway

    /* 订单和运输共同演进
     * 两个团队在履行流程上协作
     */
    OrderContext [P]<->[P] ShippingContext

    /* 客户数据共享
     * CustomerInfo值对象被多个上下文使用
     */
    OrderContext [SK]<->[SK] CustomerContext
    ShippingContext [SK]<->[SK] CustomerContext
}

诚实局限性

此技能做得好之处

从有界上下文系统识别模式
为Context Mapper工具生成CML语法
基于模式的集成策略建议
团队拓扑对齐建议
Mermaid/PlantUML图生成

需要人工输入之处

团队动态 - 实际的组织政治和关系
业务优先级 - 哪些集成最重要
遗留约束 - 限制选项的现有系统
变革意愿 - 组织重构准备情况
权衡决策 - 当多个模式可能工作时

所有输出清晰区分建议与要求，并标记不确定分类供人工审查。

参考

模式目录 - 所有8种模式与示例
CML语法 - Context Mapper DSL参考
模式选择 - 决策指南
集成策略 - 技术实施
团队拓扑 - 组织对齐

用户界面

当用户直接调用时，此技能映射有界上下文关系。

执行工作流

解析参数 - 提取有界上下文来源、模式和输出格式。如果无来源提供，检查 docs/event-storming/ 中的事件风暴输出或询问用户。
清单有界上下文 - 解析输入以获取上下文名称、职责、聚合、发布/消费事件和团队所有权。
基于模式执行：
- 完整：启动 context-mapper 代理，系统分析所有关系，附带模式选择理由和团队拓扑对齐。
- 快速：从事件对、API依赖和共享数据访问识别明显关系。应用默认模式。
- 引导：交互式逐关系确认，展示证据并提供模式建议。
生成输出 - 产生CML文件、Mermaid图、总结报告，包括模式分布和团队拓扑建议。
保存结果 - 保存到 docs/architecture/context-map.cml 和 docs/architecture/context-map.md（或自定义 --dir）。
建议后续步骤 - 推荐架构文档、ADR用于模式决策、适应度函数用于边界。

版本历史

v1.0.0 (2025-12-22)：初始发布 - 上下文映射模式、CML输出、多模式执行

最后更新： 2025-12-22 模型： claude-opus-4-5-20251101

上下文映射技能Skill context-mapping