ddd-context-mapping

一句话概述

上下文映射会记录限界上下文之间的关系，并选择一种集成模式，在边界处转换模型。

何时使用此技能

• 与其他团队的领域模型集成。
• 为新的系统间边界选择集成模式。
• 团队必须使用、但无法更改的遗留系统。
• 用户询问上下文如何交互，而不是是否应该拆分它们。

何时不要使用此技能

• 上下文内部建模 → ddd-bounded-context 或战术模式技能。
• 确定边界本身 → ddd-bounded-context。
• 决定在各子域上投入什么 → ddd-subdomain-classification。

核心内容

七种模式及其选择标准：

共享内核（Shared Kernel）。 两个上下文共同维护模型中一个小而明确共享的子集（例如，一个只包含少量值对象的共享库）。团队紧密协作时，成本较低；协作不紧密时则很脆弱——每次变更都需要双方同意。

客户方–供应方（Customer–Supplier）。 下游依赖上游；上游承诺在规划中优先考虑下游的需求。适用于上游团队愿意对下游负责的情况。

遵奉者（Conformist）。 下游接受上游的模型，不作更改并遵循该模型。仅当你无法影响上游，且遵循其模型的成本低于转换成本时才使用。这是一种有意为之的战略选择，而非偷懒。

防腐层（Anticorruption Layer，ACL）。 由下游负责的转换层，可将自身模型与陌生或不稳定的上游隔离开来。当遵循上游模型会损害自己的模型时使用——通常适用于与遗留系统或第三方 API 集成的情况。

开放主机服务（Open Host Service，OHS）。 上游提供为多个下游使用者设计的稳定协议。当 N 个或更多下游需要使用同一个上游时使用——只需为稳定接口支付一次成本。

发布语言（Published Language）。 一种正式且文档完善的交换格式（架构或协议），由多个上下文共同认可。它通常与开放主机服务配合使用。该格式是契约的一部分，而非实现细节。

各自为政（Separate Ways）。 两个上下文拒绝集成；少量重叠部分则重复实现。当集成成本高于重复实现的成本时使用——这是比团队承认的更常见的正确选择。

此外，同一模式目录中通常还会列出一种反模式：

大泥球（Big Ball of Mud）。 完全没有边界。识别它，并围绕泥球绘制上下文映射以将其隔离；通过集成接入它（通常使用 ACL），不要扩展它。

决策启发

• 针对上游的稳定接口进行集成，而非其内部实现。
• 当上游模型陌生、不稳定，或由你无法影响的团队负责时，应构建 ACL。
• 各自为政也是一种切实可行的选择；有时正确答案就是“我们不集成”。
• 遵奉者是一种战略选择。应有意选择，而非默认采用。

反模式

• 把你所依赖的遗留系统称为“模型”——它不是模型，而是一个上游上下文。
• 构建没有明确转换规则的 ACL——它会沦为透传层。
• 让不协作的团队共享内核；内核会逐渐腐化。
• 声称采用了“开放主机服务”，却没有真正稳定接口。

另请参阅

• ddd-bounded-context — 在映射关系之前，先确定边界所在。
• ddd-anti-patterns — 大泥球及其他集成反模式。

参考资料

• Evans，Domain-Driven Design（2003），第 14 章（维护模型完整性）。