Context Map Diagram（上下文映射图绘制）

解决什么问题：Context Map 必须可视化才能协作——光靠口头描述无法跨团队对齐——Context Map Diagram 提供统一的图形语言，让所有 BC 团队看到同一张图、用同一套符号。

它是什么

Context Map Diagram 是 Context Map 的可视化产物——用标准符号画出 BC + 关系的工具方法。

常用符号：

节点：BC（圆角矩形 / 圆形 / 不同色块）
边：9 种 BC 关系（不同箭头样式 / 不同颜色）
标注：U/D 方向 + 关系名（Customer-Supplier / ACL / OHS 等）
附件：Shared Kernel 子图、ACL 子图

Vernon Ch 3 强调：Context Map 必须能被所有相关团队看懂——任何技术性过强的图（UML）都不合适。

V2 视角（B4 抽象）：Context Map Diagram = 抽象 BC 间关系为可视模式——让 9 种关系成为"眼睛一扫就能识别"的符号。

关键属性

属性	值/含义
节点	BC（必须命名 + 颜色标识）
边	U→D 方向 + 关系类型（必须显式标注）
符号	推荐 Context Mapper 风格（开源工具）
粒度	一张图覆盖一个业务域（5-15 BC）
反模式	只画箭头不标关系类型
核心约束	图必须 5 分钟内可被业务专家看懂
存储	Git 仓库 + Markdown（版本化）

怎么用

场景 1：从零画 Context Map Diagram

步骤：

列出所有 BC：从 Event Storming 产出中提取
画节点：每个 BC 一个圆角矩形，标注 BC 名
识别关系：两两 BC 之间追问"谁依赖谁、怎么集成"
选符号：对照 9 种 BC 关系符号表
画边：用对应符号连接节点，标注 U/D
加附件：Shared Kernel 子图、ACL 翻译器子图

符号示例（Context Mapper 风格）：

Partnership:        A <====> B      (双向实线)
Shared Kernel:      A <====SK====> B  (双向虚线 + SK 标签)
Customer-Supplier:  A ----> B       (单向实线 + C-S 标签)
Conformist:         A ---> B        (单向虚线 + Conformist 标签)
ACL:                A ---[ACL]---> B (单向实线 + ACL 中间)
OHS:                A ---[OHS]---> B (单向实线 + OHS 中间)
PL:                 A ---[PL]---> B  (单向实线 + PL 中间)
Separate Ways:      A       B       (无连接)
BoM:                A ---~~~--> B   (波浪线 + BoM 标签)

场景 2：用 Context Mapper 工具生成

Context Mapper 是开源 DSL + 可视化工具：

BoundedContext OrderContext
BoundedContext PaymentContext

ContextMap OrderContext_PaymentContext {
    type = SYSTEM_LANDSCAPE
    state = TO_BE
    
    contains OrderContext, PaymentContext
    
    OrderContext [D]<-[U] PaymentContext {
        relationship = CustomerSupplier
        realization = OrderContext.paymentDomainEvent
    }
}

工具：IntelliJ + Context Mapper 插件（自动渲染图）。

场景 3：用 Mermaid / PlantUML 简化画图

Mermaid 风格（VitePress 原生支持）：

mermaid

flowchart LR
    Order[订单 BC] -->|Customer-Supplier| Payment[支付 BC]
    Order -->|ACL| LegacyCRM[遗留 CRM]
    Inventory[库存 BC] -.->|Shared Kernel| Order

优点：Markdown 直接嵌入，Git 版本化友好。

场景 4：审计和演化追踪

步骤：

把 Context Map Diagram 存入 Git
每次 BC 关系变化——提交 PR 改动 Context Map
每次 PR 必须包含 Context Map 更新——Code Review 检查
季度回顾：识别"关系漂移"（Conformist 增多？ACL 减少？）

常见误区

"画得太漂亮 = 好"——错。Context Map 是协作工具，不是艺术品。清晰胜过美观
"用 Visio / Figma 画"——可以，但必须存 Git + Markdown。版本化比工具重要
"一张图画全公司"——错。超过 20 个 BC = 信息过载。按业务域分图（电商图 / 金融图 / 内部工具图）
"关系用箭头就够了"——错。箭头只能表达方向，不能表达类型。必须标关系名（C-S / ACL / Conformist）
"Context Map Diagram 一次性画完"——错。它是动态文档——每季度审查更新
"UML 类图表达 BC 关系"——错。UML 类图表达静态结构，Context Map 表达协作权力。两者不替代

关键洞察

Context Map Diagram 不是"架构图"——它是"协作合同"——所有相关团队对 BC 间关系的共识。
可视化 = 降低沟通成本
符号化 = 关系类型显式化
版本化 = 演化可追溯
这是 V2 B4 抽象的工程化——把 9 种 BC 关系抽象为统一符号。
判断 Context Map Diagram 是否生效 = 任何团队成员能独立画出当前图（不靠口头解释）。 判断失败 = 团队对"我们 BC 和谁是什么关系"答案不一致。

Context Map Diagram（上下文映射图绘制） ​

它是什么 ​

关键属性 ​

怎么用 ​

场景 1：从零画 Context Map Diagram ​

场景 2：用 Context Mapper 工具生成 ​

场景 3：用 Mermaid / PlantUML 简化画图 ​

场景 4：审计和演化追踪 ​

常见误区 ​

关键洞察 ​

相关链接 ​