战略模式：上下文映射

战略模式：上下文映射围绕 8 个章专属概念，以边界模型、决策轨迹、违规恢复和来源分层完成验收。

学习目标

能解释“战略模式：上下文映射”如何先记录上下文之间真实的模型与团队关系，再按控制力、协作成本和翻译需求选择集成模式
能逐项定位上下文映射、共享内核、客户—供应商、遵奉者、防腐层、开放主机服务与发布语言、各行其道、大泥球，并说明每个概念在当前来源边界内承担什么责任
能按盘点上下文 → 标出上下游 → 评估控制力 → 选择关系模式 → 定义版本与退出条件推演“支付平台接入”，检查“每条上下文关系都有方向、所有者和语义合同，任何共享或遵奉选择都明确其变化传播代价”
能注入“把 Context Map 画成无方向的系统调用拓扑，忽略上下游权力和模型翻译”，依据上下文地图、上下游方向、团队承诺、共享代码所有者、翻译测试、发布语言版本与退出条件定位越界、撤销并用同一情境重放

为什么从“承认现有关系而不是粉饰它，根据双方控制力选择共享、协作、翻译、遵奉或彻底分离”开始

先记录上下文之间真实的模型与团队关系，再按控制力、协作成本和翻译需求选择集成模式。本页先画责任和依赖，再沿具体情境执行决策，最后主动制造一个边界违规；这种顺序把术语变成可以验证、推翻和恢复的设计合同。

“战略模式：上下文映射”不是技术采购建议。它处理的是规则放在哪里、模型在哪个语境内成立、哪些变化可以被隔离，以及团队如何判断一条边界已经被穿透。最终功能可运行，只能证明快乐路径存在，不能证明结构允许安全演进。

来源、版次与课程边界

上下文映射关系名称与意图来自 Evans 官方参考摘要；组织案例、退出条件和测试方法为独立教学设计，不复制原书叙事。

本专题不是某一本既有书的中文版，也不是把多位作者的文章拼成“原著章节”。课程主干分别取自 Eric Evans 的领域驱动设计体系与 Robert C. Martin 的整洁架构体系；CQRS、事件溯源和六边形架构始终标为扩展。以下链接承担不同事实责任：

Pearson: Domain-Driven Design：核对 Eric Evans、第一版、出版信息与原书身份，不据此声称拥有全文
Eric Evans: Domain-Driven Design Reference：核对 DDD 定义、模式摘要、增补范围与 CC 授权说明
Domain-Driven Design Reference PDF：核对分层、限界上下文、战术模式和上下文映射的公开摘要正文

本页采用独立中文重写。能从公开全文或授权摘要核对的定义才作为来源事实；项目情境、交互实验、取舍表和练习答案均为本站教学设计。

核心概念与可观察责任

上下文映射

上下文映射给出模型边界及其关系的全局视图，重点是语义与团队协作，不只是网络连接或数据流拓扑。在“支付平台接入”中，观察重点是每条上下文关系都有方向、所有者和语义合同，任何共享或遵奉选择都明确其变化传播代价。

共享内核

两个上下文共同拥有一小部分模型与代码，任何修改都需协商和同步测试；共享范围必须刻意保持很小。在“共享税则模型”中，观察重点是上下文地图、上下游方向、团队承诺、共享代码所有者、翻译测试、发布语言版本与退出条件。

客户—供应商

上游供应商根据下游客户的明确需求规划接口，下游可以协商优先级；关系是否有效取决于真实合作承诺。在“支付平台接入”中，观察重点是每条上下文关系都有方向、所有者和语义合同，任何共享或遵奉选择都明确其变化传播代价。

遵奉者

下游无力影响上游且翻译收益不足时，主动遵从上游模型；这是成本选择，不应伪装成共享语言。在“共享税则模型”中，观察重点是上下文地图、上下游方向、团队承诺、共享代码所有者、翻译测试、发布语言版本与退出条件。

防腐层

下游用翻译层隔离外部模型，使内部通用语言不被上游概念侵入；它承担适配与语义转换而非简单转发。在“支付平台接入”中，观察重点是每条上下文关系都有方向、所有者和语义合同，任何共享或遵奉选择都明确其变化传播代价。

开放主机服务与发布语言

上游用稳定协议服务多个消费者，并发布可共同理解的交换语言，减少每个下游都建立专用集成的成本。在“共享税则模型”中，观察重点是上下文地图、上下游方向、团队承诺、共享代码所有者、翻译测试、发布语言版本与退出条件。

各行其道

当集成价值低于协作和翻译成本时，两个上下文保持分离并各自解决问题，避免为了统一而制造更大耦合。在“支付平台接入”中，观察重点是每条上下文关系都有方向、所有者和语义合同，任何共享或遵奉选择都明确其变化传播代价。

大泥球

边界混乱的系统应被明确标记和隔离，外部上下文不要假设其内部模型稳定；新增开发应避免继续扩大污染范围。在“共享税则模型”中，观察重点是上下文地图、上下游方向、团队承诺、共享代码所有者、翻译测试、发布语言版本与退出条件。

一条可执行的设计判断

本页采用以下判断链：承认现有关系而不是粉饰它，根据双方控制力选择共享、协作、翻译、遵奉或彻底分离。正常情况下必须持续保持“每条上下文关系都有方向、所有者和语义合同，任何共享或遵奉选择都明确其变化传播代价”；反例“把 Context Map 画成无方向的系统调用拓扑，忽略上下游权力和模型翻译”只改变一个关键条件，便于定位因果。

观察项	本页合同
最小正常情境	支付上游无法按订单团队的术语修改接口
边界或迁移情境	两个团队共同维护很小且高价值的税率计算内核
必须保持	每条上下文关系都有方向、所有者和语义合同，任何共享或遵奉选择都明确其变化传播代价
首要违规	把 Context Map 画成无方向的系统调用拓扑，忽略上下游权力和模型翻译
验收证据	上下文地图、上下游方向、团队承诺、共享代码所有者、翻译测试、发布语言版本与退出条件

先预测，再操作三个本页实验

分步1 / 3

实验一：边界与模型地图

操作前先预测“支付平台接入”里哪一侧拥有规则、哪一侧只是技术或协作细节。切换概念和情境后，检查“承认现有关系而不是粉饰它，根据双方控制力选择共享、协作、翻译、遵奉或彻底分离”是否仍能解释三块区域的责任。

Boundary model

战略模式：上下文映射：边界与责任地图

先记录上下文之间真实的模型与团队关系，再按控制力、协作成本和翻译需求选择集成模式

切换最小情境

定位正式概念

architecturedomaindesign-09 · 当前观察

上下文映射：支付上游无法按订单团队的术语修改接口

区域 1上游模型

决定能力、发布节奏与交换合同

↓

区域 2关系策略

共享、协商、遵奉、翻译或分离

↓

区域 3下游模型

决定接受、保护或拒绝外部语义

情境验收

订单侧建立防腐层，把支付状态翻译为本地履约语言

易错边界与取舍

练习与答案

练习

问题 1：概念—边界—证据对照。 完成以下逐项核对：

上下文映射：写出它所在的边界、允许的依赖方向、一个最小反例和一份可观察证据。
共享内核：写出它所在的边界、允许的依赖方向、一个最小反例和一份可观察证据。
客户—供应商：写出它所在的边界、允许的依赖方向、一个最小反例和一份可观察证据。
遵奉者：写出它所在的边界、允许的依赖方向、一个最小反例和一份可观察证据。
防腐层：写出它所在的边界、允许的依赖方向、一个最小反例和一份可观察证据。
开放主机服务与发布语言：写出它所在的边界、允许的依赖方向、一个最小反例和一份可观察证据。
各行其道：写出它所在的边界、允许的依赖方向、一个最小反例和一份可观察证据。
大泥球：写出它所在的边界、允许的依赖方向、一个最小反例和一份可观察证据。

对每个概念先确定它属于业务政策、模型协作还是外部技术，再画允许的依赖方向。用“支付上游无法按订单团队的术语修改接口”建立正常基线，用“把 Context Map 画成无方向的系统调用拓扑，忽略上下游权力和模型翻译”作为单一反例，最后从上下文地图、上下游方向、团队承诺、共享代码所有者、翻译测试、发布语言版本与退出条件中找第一处不一致。

问题 2：最小情境推演。 怎样验证“支付平台接入”没有靠最终功能碰巧通过？

按盘点上下文 → 标出上下游 → 评估控制力 → 选择关系模式 → 定义版本与退出条件保存每步状态，预期结果是“订单侧建立防腐层，把支付状态翻译为本地履约语言”。最终输出之外，还要逐步确认“每条上下文关系都有方向、所有者和语义合同，任何共享或遵奉选择都明确其变化传播代价”；任一中间状态越界都应拒绝当前设计。

问题 3：替代方案与恢复。 注入“把 Context Map 画成无方向的系统调用拓扑，忽略上下游权力和模型翻译”后，怎样比较修复与更简单方案？

先保留故障前的上下文地图、上下游方向、团队承诺、共享代码所有者、翻译测试、发布语言版本与退出条件，再记录首个越界位置。分别实施最小修复和删除多余模式的方案，用同一个“两个团队共同维护很小且高价值的税率计算内核”重放；选择仍满足“明确共享内核所有者、联合测试和变更协商，不扩大共享范围”且依赖更少的方案。

本页小结

战略模式：上下文映射的核心判断是：承认现有关系而不是粉饰它，根据双方控制力选择共享、协作、翻译、遵奉或彻底分离。
正常路径以“订单侧建立防腐层，把支付状态翻译为本地履约语言”验收，不能只检查接口返回成功。
边界路径以“明确共享内核所有者、联合测试和变更协商，不扩大共享范围”验收，并保存上下文地图、上下游方向、团队承诺、共享代码所有者、翻译测试、发布语言版本与退出条件。
如果“把 Context Map 画成无方向的系统调用拓扑，忽略上下游权力和模型翻译”仍可静默通过，说明边界只是图示，没有成为可执行约束。