L4 - 上下文映射（Context Maps）

Context Map = BC 间关系的显式建模——一张图 + 一份文档 + 一组翻译。不是 Enterprise Architecture，不是系统拓扑，是"团队间关系的真相"。

一句话

Context Map = 当前 BC 布局 + BC 间关系类型 + 翻译方式——是团队"自我审视"的工具。关系不对，再好的 BC 也失败。

这本书在这一层说了什么

本层基于 IDDD Ch 3 + Evans《Domain-Driven Design》Reference。

Vernon 开篇 Emerson 引言：

"Whatever course you decide upon, there is always someone to tell you that you are wrong. There are always difficulties arising which tempt you to believe that your critics are right. To map out a course of action and follow it to an end requires courage."

Vernon 对 Context Map 的定义：

"The Context Map of a project can be expressed in two ways. The easier way is to draw a simple diagram that shows the mappings between two or more existing Bounded Contexts... The more detailed way to express Context Maps is as the source code implementations of the integrations."

核心论点 3 个：

1. Why Context Maps Are So Essential — 为什么必须画
2. Projects and Organizational Relationships — 7 大关系 + 3 大组织
3. Mapping the Three Contexts — SaaSOvation 实战

是什么

1. 为什么 Context Maps 不可省

Vernon 关键论断：

"When you start out on a DDD effort, first draw a visual Context Map of your current project situation."

Vernon 警告：

"Context Maps will be hidden in plain sight unless the team pays regular attention to them through meaningful discussion."

反例（Vernon SaaSOvation 早期）：

"When the CollabOvation team first started developing its greenfield model, they should have used a Context Map. Even though they were nearly starting from scratch, stating their assumptions about the project in the form of a Map would have prompted them to think about separate Bounded Contexts."

教训：即使是 greenfield（新项目），也必须先画 Map。

2. Drawing Context Maps（绘制技巧）

Vernon 的"白板时间"原话：

"Whiteboard Time Draw a simple diagram of your current project situation that communicates at a high level where the boundaries are, the relationships between them and their teams, what kinds of integrations are involved, and the necessary translations between them."

Vernon 的关键忠告：

该做	不该做
手绘 + 白板	复杂工具 / 企业级 EA 工具
当前现状	想象中的未来
高层边界 + 关系 + 翻译	详细技术拓扑
团队关注 + 讨论	"贴墙上没人看"

Vernon 关于"未来的现状"：

"First you should map the present, not the imagined future. If the landscape will change as your current project progresses, you can update the Map at that time."

Evans Reference 原话（Vernon 引用）：

"Identify each model in play on the project and define its BOUNDED CONTEXT... Name each BOUNDED CONTEXT, and make the names part of the UBIQUITOUS LANGUAGE. Describe the points of contact between the models, outlining explicit translation for any communication and highlighting any sharing."

3. Context Maps 的两大视角

Vernon 论断：

"The information is conveyed relative to interacting models and DDD organizational patterns."

视角	内容
模型视角	BC 边界 + 模型翻译 + 集成方式
组织视角	团队关系 + 协作模式 + Conway 定律

Vernon 关键洞察：

"Context Maps may even help us identify sticky governance issues that could block progress, and other team and management challenges."

4. 7 大关系模式（Vernon 引用 Evans + 整合）

Vernon 原话（大部分模式定义引自 Evans）：

"Each of the following definitions is largely quoted from [Evans, Ref]."

关系 1: Partnership（合作关系）

Vernon 引用 Evans：

"When teams in two Contexts will succeed or fail together, a cooperative relationship needs to emerge. The teams institute a process for coordinated planning of development and joint management of integration. The teams must cooperate on the evolution of their interfaces to accommodate the development needs of both systems. Interdependent features should be scheduled so that they are completed for the same release."

特征：

• 两个 BC 同等重要（都成败攸关）
• 联合规划 + 联合管理
• 接口同步演化

判断：两个 BC 是核心域，且紧密依赖 → Partnership。

关系 2: Shared Kernel（共享内核）

Vernon 引用 Evans：

"Sharing part of the model and associated code forms a very intimate interdependency, which can leverage design work or undermine it. Designate with an explicit boundary some subset of the domain model that the teams agree to share. Keep the kernel small. This explicit shared stuff has special status and shouldn't be changed without consultation with the other team. Define a continuous integration process that will keep the kernel model tight and align the Ubiquitous Language of the teams."

特征：

• 两个 BC 共享一部分模型 + 代码
• 共享部分有"特殊地位"
• 修改需双方协商

警告："Keep the kernel small" — 内核越大，耦合越重。

关系 3: Customer-Supplier Development（客户-供应商）

Vernon 引用 Evans：

"When two teams are in an upstream-downstream relationship, where the upstream team is motivated by the success of the downstream... The upstream team must take care to provide what the downstream team needs. The downstream team must take care to plan for features that will affect the upstream team."

特征：

• 上游团队 = 供应商（提供 API/事件/数据）
• 下游团队 = 客户（消费上游）
• 不对称权力：上游有 SLA 义务

判断：上游团队对下游的成败负责 → Customer-Supplier。

关系 4: Conformist（顺从者）

Vernon 引用 Evans：

"When the upstream team has no motivation to support the downstream team's goals... The downstream team eliminates any translation layer between them and the upstream model, and instead conforms to the upstream model."

特征：

• 上游团队不关心下游
• 下游团队放弃翻译 → 直接用上游模型
• 节省翻译成本 + 但接受上游变化风险

判断：上游不受控 + 翻译成本高 → Conformist。

关系 5: Anti-Corruption Layer（防腐层, ACL）

Vernon 引用 Evans：

"When the downstream team has no motivation to support the upstream team's goals... The downstream team insulates itself from the upstream model by translating the upstream model into its own model. The translation is done by an Anti-Corruption Layer, which is a separate and well-defined part of the design."

特征：

• 上游团队不关心下游
• 下游团队翻译上游模型 → 保护自己
• ACL 是独立的代码层

判断：上游不受控 + 业务关键 → ACL（保护自己）。

关系 6: Separate Ways（独立发展）

Vernon 引用 Evans：

"Declare a bounded context to have no connection to the others at all... The two Contexts accept that they can satisfy their needs without any influence from each other."

特征：

• 两个 BC 无集成
• 各自独立演化
• 集成成本 > 收益

判断：两个 BC 几乎无业务关系 → Separate Ways。

关系 7: Open Host Service（开放主机服务）

Vernon 引用 Evans：

"When a subsystem has to provide services to a wide variety of other systems, it can provide a public protocol of well-defined services... Define a protocol that gives access to your model's capabilities as a set of services."

特征：

• 上游 BC 提供"公共协议"
• 多个下游消费
• 接口稳定 + 文档化

判断：上游被多个下游依赖 → Open Host Service。

Plus 附赠模式：Published Language（发布语言）——上下游用共同的语言（如 Avro Schema）通信。

5. SaaSOvation 三大 BC 关系实战

Vernon 三个 BC：

1. CollabOvation（协作）— 早期核心域，现在变成 Supporting
2. IdOvation（身份）— Generic Subdomain
3. ProjectOvation（敏捷 PM）— 新核心域

关系图：

ProjectOvation（新核心域）
  ├─→ IdOvation（Generic, Open Host Service）
  └─→ CollabOvation（Supporting, Open Host Service）

CollabOvation
  └─→ IdOvation（Generic, Open Host Service）

IdOvation
  └─ 独立 BC，被多个 BC 消费

Vernon 关系判断：

• ProjectOvation ↔ CollabOvation = Open Host Service（CollabOvation 暴露 API）
• 任一 ↔ IdOvation = Open Host Service（IdOvation 暴露认证 API）

6. 关系选择决策树

决策树：
  Q1: 两 BC 是否成败与共？
    是 → Partnership
    否 ↓
  Q2: 上游团队受下游影响吗？
    是 → Customer-Supplier
    否 ↓
  Q3: 下游能保护自己（翻译）吗？
    能 → ACL（Anti-Corruption Layer）
    不能 → Conformist
    不需保护 → Conformist（节省成本）

7. SaaSOvation 上下文映射（Vernon 实战图）

                    +----------------+
                    |   ProjectOvation  |
                    |   (Core Domain) |
                    +-------+--------+
                            |
                +-----------+-----------+
                v                       v
       +--------+--------+      +-------+--------+
       | CollabOvation |      |    IdOvation    |
       |  (Supporting) |      | (Generic)       |
       +----------------+      +----------------+

翻译点：

• ProjectOvation → CollabOvation：领域事件 + ACL
• ProjectOvation → IdOvation：Open Host Service（认证 API）
• CollabOvation → IdOvation：Open Host Service（同上）

为什么

为什么必须画 Context Map？

根因 1：关系错误是项目失败的常见原因

Vernon 案例：

"Imagine what would happen if your team assumes that the team maintaining the muddy monolith will provide new APIs that you are depending on, but they don't intend to provide them, or they don't even know what you are thinking. Your team is counting on a Customer-Supplier relationship with the mud. The legacy team, however, by providing only what they currently have, forces your team into an unexpected Conformist relationship."

关键洞察：未识别的关系 = 隐藏风险。画 Map 才能显化。

根因 2：组织动态决定集成方式

Vernon 论断：

"Because they exhibit an organizational dynamic, Context Maps may even help us identify sticky governance issues that could block progress."

根因 3：沟通催化剂

Vernon 论断：

"Besides giving you an inventory of systems you must interact with, a Context Map serves as a catalyst for inter-team communication."

为什么不能用企业 EA 工具画 Context Map？

Vernon 警告：

"It's been said that a wiki can be a place where information goes to die."

根因：

• 复杂工具 → 学习成本高
• 企业 EA 工具 → 过度形式化
• 真正有用的是"团队日常讨论 + 白板"

Vernon 关键论断：

"The more ceremony you add, the fewer people will want to use the Map. Putting too much detail in diagrams won't really help the team. Open communication is the key."

怎么做

Step 1：当前现状画图（不是未来）

操作：
  1. 团队聚集 + 白板
  2. 列出当前所有 BC（不是未来的）
  3. 标注 BC 间的集成方式
  4. 标注团队归属
  
工具：
  - 白板 + 干擦笔（首选）
  - 简单图表工具（Mermaid / Excalidraw）
  - 不用企业 EA 工具（Visio / Archi）

Step 2：识别关系类型

对每对 BC：
  1. 标注上下游（U / D）
  2. 标注关系类型（7 大之一）
  3. 标注翻译点（ACL / 事件 / API）

Step 3：识别翻译成本

每对集成 BC：
  1. 翻译在哪实现（哪个 BC 负责 ACL）？
  2. 翻译工作量（多少字段 / 多少规则）？
  3. 翻译可靠性（上游变化 → 下游如何应对）？

Step 4：定期审视

触发更新的事件：
  - 新 BC 上线
  - BC 间关系变化（如从 Customer-Supplier 变 Conformist）
  - 团队重组
  - 集成失败

Step 5：团队日常讨论

Vernon 论断：

"Context Maps will be hidden in plain sight unless the team pays regular attention to them through meaningful discussion."

操作：

• 贴墙上（团队区域）
• 每周回顾（站会讨论）
• 每次架构变更（更新 Map）

什么时候用 / 什么时候不用

用 Context Map 的 2 大场景

场景	关键判断
多 BC + 多团队	必须画，否则集成失败
BC 间关系复杂（多种关系并存）	必须画，否则关系混乱

不用 Context Map 的 1 大场景

场景	原因
单 BC + 单团队	Context Map 是过度形式化

看不见的地方

失效模式 1：未识别的关系 = 隐藏风险

症状：团队假设 X 关系，实际是 Y 关系 → 集成失败。

Vernon 案例：

"Your team is counting on a Customer-Supplier relationship with the mud. The legacy team... forces your team into an unexpected Conformist relationship."

根因：未画 Map → 关系假设错误。

修复：画 Map + 主动沟通 + 验证关系假设。

失效模式 2：Wiki 上画 Map 没人看

症状：Map 画了但没人更新、没人参考。

根因：脱离团队日常。

修复：白板 + 团队区域 + 每周讨论。

失效模式 3：关系类型混淆

症状：把 Conformist 当 ACL → 没翻译 → 上游变化破坏下游。

根因：未理解 7 大关系的本质差异。

修复：看决策树 + 严格区分。

失效模式 4：Shared Kernel 过大

症状：共享内核从 10% 涨到 50% → 修改需大量协调。

根因：未控制 Shared Kernel 范围。

修复：Evans 警告"Keep the kernel small" + 定期审视共享范围。

失效模式 5：上下游搞反

症状：标 Upstream 实际是 Downstream → 翻译方向错。

根因：未理解上下游 = 集成方向。

修复：上下游由"数据/事件流向"决定（不是由"团队重要性"决定）。

失效模式 6：Map 画了不更新

症状：Map 与实际架构脱节 → 参考 Map 决策 → 决策错误。

根因：无更新机制。

修复：每次架构变更 = 强制更新 Map。

失效模式 7：把 Map 当 Enterprise Architecture

症状：Map 包含所有系统、组件、网络 → 失去焦点。

根因：未理解 Map 是"BC 间关系"。

修复：只画 BC 边界 + 关系 + 翻译，不画技术细节。

相关节点

骨架 A — 世界观

节点	关联	解释
wonder-04-encounter	强	BC 间关系 = "照面"模式——ACL/Open Host/Partnership 都是照面方式
wonder-05-concealment	中	未识别的关系 = "隐匿"——隐藏风险

骨架 B — 工程实践

节点	关联	解释
change-management	强	Context Map = 变更管理的基础设施——变更前先看 Map
feedback-mechanisms	中	团队讨论 Map = 反馈机制——团队对架构的反馈

与 IDDD 其他层对位

层	关系
L3 限界上下文	L4 基于 L3 的 BC 划分，画 BC 间关系
L8 跨 BC 集成	L8 是 L4 的工程实现（ACL / 事件 / HTTP 等）

与 EDM 对位

EDM	IDDD L4
Ch 4 CDC	L4 ACL 的事件版（CDC = 数据级 ACL）
Ch 8 Saga	L4 Customer-Supplier 关系的工程实现

与海德格尔对位

Vernon 的"BC 间翻译"= 海德格尔的"世界之间的转换"：

• 一个 BC 是"一个世界"
• BC 间翻译 = "两个世界之间的诠释"
• ACL = 翻译的具体技术
• Conformist = "放弃翻译、接受对方世界"
• Partnership = "双向翻译、共同演化世界"

状态

L4 概念递进落地完成（基于原书 ch03 48KB / 7653 词）。

• 7 大关系模式（Vernon 引用 Evans 完整定义）
• SaaSOvation 三大 BC 实战
• 关系选择决策树
• 7 个失效模式
• 骨架 A/B + IDDD + EDM + 海德格尔 4 重共振映射