9 种 BC 关系 = 上下游权力图

一、业务问题

微服务架构下，BC 之间如何协作是核心难题：

"我们 BC 要不要听别人的？"
"上游变了，我们要跟着改吗？"
"两个 BC 强耦合，怎么解？"
"如何用最小代价集成？"

Vernon 在 Ch 3 给出 9 种 BC 关系——这是 DDD 战略层最实用的方法论。

二、控制论视角

9 种关系 = 多变量系统的耦合模式

U (Upstream) = 提供方，影响下游
D (Downstream) = 消费方，被影响

控制论对位：
  - 紧耦合 = 矩阵非对角元素大
  - 松耦合 = 矩阵接近对角化
  - 无耦合 = 完全对角化（Separate Ways）

钱学森 Ch 6 §6.3：

"设法确定控制矩阵的元素……须要满足什么条件，才能使规定的控制信号只影响和它们相应的受控量……而不影响其余的受控量。"

软件对位：BC 关系 = 矩阵对角化的工程实现。

三、9 种关系详解

3.1 关系总览（按协作紧密排序）

#	关系	上游权力	下游权力	协作紧密	适用
1	Partnership	平等	平等	最高	共同命运
2	Shared Kernel	共享	共享	高	共同基础
3	Customer-Supplier	强	弱	中	内部清晰
4	Conformist	极强	极弱	低	不可改变
5	Anticorruption Layer	强	中（有保护）	中	保护核心
6	Open Host Service	标准	多客户	高	多下游
7	Published Language	通用	通用	高	跨组织
8	Separate Ways	无	无	无	不集成
9	Big Ball of Mud	混乱	依赖	无	遗留系统

3.2 各种关系详解

Partnership（伙伴关系）

特点：
  - 两个 BC 共同演化
  - 团队紧密协作
  - 同步计划 + 共同管理
  - 互相妥协
  
适用：
  - 两个 BC 都要成功或失败
  - 团队愿意紧密合作
  
反模式：
  - 团队分散在不同部门
  - 没有共同目标

Shared Kernel（共享内核）

特点：
  - 两个 BC 共享部分模型
  - 共享代码（共同基础类型）
  - 必须协商修改
  
适用：
  - 共同基础（如共同 UserId 类型）
  - 改造成本大于收益
  
反模式：
  - 共享过多（耦合失控）
  - 没有变更管理

Customer-Supplier（客户-供应商）

特点：
  - 上游 = 供应商（影响大）
  - 下游 = 客户（影响小）
  - 供应商有动力服务客户
  
适用：
  - 内部团队、上下游清晰
  - 供应商愿意配合

Conformist（跟随者）

特点：
  - 下游完全接受上游变化
  - 不抵抗、不翻译
  - 单边依赖
  
适用：
  - 上游不可改变
  - 改造下游比跟随便宜
  
反模式：
  - 实际可谈判但放弃
  - 积累技术债

Anticorruption Layer（防腐层）

特点：
  - 下游加翻译层
  - 隔离上游变化
  - 保护本地下游
  
适用：
  - 上游不能/不会改变
  - 下游有清晰核心模型
  - 不能 Conformist

实现：
  [上游] → [ACL 翻译] → [下游核心模型]

Open Host Service（开放主机服务）

特点：
  - 上游提供稳定 API
  - 多客户可接入
  - 协议随业务演化
  
适用：
  - 多个下游依赖同一上游
  - 上游有能力维护稳定 API

Published Language（发布语言）

特点：
  - 通用语言 = 跨 BC 通信标准
  - XML/JSON Schema / 行业标准
  - 上游下游都遵守
  
适用：
  - 跨组织、跨行业集成
  - 需要标准化的领域对象

Separate Ways（各行其道）

原则：
  - "Be ruthless"
  - 集成成本 > 收益时切割
  - 不强求集成
  
适用：
  - 业务可独立
  - 重复实现比集成便宜

Big Ball of Mud（混乱大泥球）

特点：
  - 遗留系统的现状
  - 没有清晰 BC
  - 边界模糊
  
应对：
  - 不重写（成本太高）
  - 加 ACL 隔离
  - 逐步拆分（新功能在 DDD 上下文）

四、上下游权力图

                上游权力
              弱          强
        ┌──────────┬──────────┐
   善   │Customer- │Partnership│
        │Supplier  │Shared     │
        │          │Kernel     │
  下游  ├──────────┼──────────┤
   态度  │          │           │
        │Conformist│ACL        │
   恶   │(无保护)  │(有保护)   │
        │Separate  │Big Ball   │
        │Ways      │of Mud     │
        └──────────┴──────────┘

关键判断：

上下游权力 + 善恶 = 关系选择
善 = 愿意合作
恶 = 不愿/不能合作

五、关系选择决策表

业务场景	推荐关系
内部团队、共同命运	Partnership
内部团队、有共同基础	Shared Kernel
内部团队、上下游清晰	Customer-Supplier
外部不可改变 SaaS	Conformist
外部不可改变 + 核心要保护	ACL
多个下游 + 标准化	OHS
跨组织行业	OHS + Published Language
集成成本 > 收益	Separate Ways
遗留系统	ACL + 逐步拆分

六、工程实践

实战 1：画 Context Map

步骤：
  1. 列出所有 BC
  2. 标出每个 BC 的上下游关系
  3. 用 Vernon 9 种关系标注
  4. 识别问题关系（Conformist 太多？ACL 太少？）
  5. 规划改进路径

例：电商 Context Map
  [Identity BC] -U-> [Order BC]
  [Identity BC] -U-> [Inventory BC]
  [Order BC] -U-> [Payment BC] (Customer-Supplier)
  [Order BC] -D-> [Legacy CRM] (Conformist)
  [Order BC] -D-> [External Payment] (ACL)
  [Analytics BC] <- Separate Ways

实战 2：避免大泥球蔓延

策略：
  - 新功能放在新的 DDD BC
  - 旧功能不主动改造
  - 边界用 ACL 隔离
  - 逐步从大泥球拆出干净的 BC

实战 3：识别 Partnership 的可行性

判断标准：
  □ 两个团队的命运绑定？
  □ 两个团队都能投入资源？
  □ 有共同的 OKR？
  □ 团队愿意紧密协作？
  
  ≥ 3 个 ✓ → Partnership
  否则 → Customer-Supplier / Conformist / ACL

七、性能指标

指标	衡量
Context Map 完整度	多少 BC 关系被识别
ACL 覆盖率	多少混乱集成被翻译保护
跨 BC 协调时间	跨 BC 变更的平均时间
关系类型分布	各种关系类型的占比

八、边界判断

何时用 Partnership：

团队紧密协作 + 共同命运

何时用 Customer-Supplier：

上下游清晰 + 上游有动力

何时用 Conformist：

上游不可改变 + 接受依赖

何时用 ACL：

上游不可改变 + 下游有核心模型要保护

何时用 OHS/PL：

多下游 + 标准化需求

何时用 Separate Ways：

集成成本 > 收益

何时承认 Big Ball of Mud：

遗留系统 + 无力重写

九、与其他 L 层方法论的关系

方法论	关系
bounded-context	BC 是关系的主体
subdomain	子域类型影响关系选择
anti-corruption-layer	ACL 是一种关系
shared-kernel	Shared Kernel 是一种关系
customer-publisher	Customer-Supplier 关系

十、钱学森原话

Ch 6 §6.3（解耦条件）： "设法确定控制矩阵的元素……才能使规定的控制信号只影响和它们相应的受控量……而不影响其余的受控量。"

Ch 6 §6.7（耦合取舍）： "受控对象中的相互关联并不总是有害的……有些耦合作用是有益的。"

十一、总结

9 种 BC 关系 = BC 集成的完整决策空间：

关键维度	选择
协作紧密	Partnership > Shared Kernel > Customer-Supplier > ... > Separate Ways
保护策略	ACL（有保护）vs Conformist（无保护）
标准化	OHS/PL（标准化）vs 自定义（灵活）

核心原则：

关系选择不是技术问题——是权力 + 协作问题
下游有保护总是更好（除非改造成本太高）
Separate Ways 是合理选择——不强求集成
承认 BoM——遗留系统不假装是 DDD

一句话总结：9 种 BC 关系 = 按上下游权力 + 协作意愿选择合适的耦合模式。

9 种 BC 关系 = 上下游权力图 ​

一、业务问题 ​

二、控制论视角 ​

三、9 种关系详解 ​

3.1 关系总览（按协作紧密排序） ​

3.2 各种关系详解 ​

Partnership（伙伴关系） ​

Shared Kernel（共享内核） ​

Customer-Supplier（客户-供应商） ​

Conformist（跟随者） ​

Anticorruption Layer（防腐层） ​

Open Host Service（开放主机服务） ​

Published Language（发布语言） ​

Separate Ways（各行其道） ​

Big Ball of Mud（混乱大泥球） ​

四、上下游权力图 ​

五、关系选择决策表 ​

六、工程实践 ​

实战 1：画 Context Map ​

实战 2：避免大泥球蔓延 ​

实战 3：识别 Partnership 的可行性 ​

七、性能指标 ​

八、边界判断 ​

九、与其他 L 层方法论的关系 ​

十、钱学森原话 ​

十一、总结 ​