限界上下文：给每块子域画一条语义边界

全章用「云市」电商交易平台贯穿。它有五个限界上下文：目录 Catalog（商品展示）、销售 Sales（下单与订单状态机，核心域）、库存 Inventory（可用量与仓位）、配送 Shipping（运单与签收）、支付 Payment（收款与退款）。这五块边界是本章从头到尾的工作台。

3.1一词多义 Polysemy：代码无法靠语境自动消歧

同一个业务词在不同上下文里指向不同的对象；对话能靠语境消歧，代码不能——一个统一类会把矛盾的字段全堆在一起。

底层机制（比定义深一层）：把云市的「商品 Product」摊开看，它在四个上下文里是四个不同对象。目录 Catalog 里它很「胖」：标题、详情、图集、类目、参数、营销文案。销售 Sales 里它是一张下单快照：productId + 名称快照 + 单价快照——价格在下单那一刻被冻结，之后目录改价不影响已下的订单。库存 Inventory 里它只是 Sku + 可用数量 + 仓位，不关心标题和图片。配送 Shipping 里它退化成重量、体积、件数。强行做一个企业级统一的 Product，等于让一个类同时背负营销文案和仓位编号，每个使用方都被迫看见自己永远不用的一半字段。

「客户 Customer」是同一根刺：销售 Sales 里它是下单方 买家 Buyer；支付 Payment 里它是付款方 付款方 Payer（账户、支付方式）；营销里它是会员 Member（等级、积分）。Buyer、Payer、Member 在数据库里往往指向同一个自然人，但它们在各自上下文里要回答的问题完全不同，硬合成一个 Customer 类只会让三组逻辑互相绊脚。

与下一节的关系：既然一个词在不同地方就是不同的对象，那就需要一条边界把「这个词在这里的唯一含义」框起来。这条边界就是限界上下文。

3.2限界上下文 Bounded Context：一套语言一致的边界

限界上下文（Bounded Context）是一个模型、一套统一语言（Ubiquitous Language）保持一致的明确边界；同一个词在两个上下文里就是两个不同的类。

底层机制（比定义深一层）：限界上下文的「界」限的是语言和模型，不是数据或代码目录。判断两段业务该不该同属一个上下文，标准是一个词在这里是否始终只有一个含义。云市的 Sales 上下文里，「商品」永远指那张价格冻结的下单快照、「客户」永远指 Buyer，团队、产品、代码用的是同一套词；Inventory 上下文里「商品」永远指 Sku + 数量。两个上下文都有「商品」这个词，但它们映射到两个不同的类——这不是命名冲突，而是事实：仓库关心的商品和详情页关心的商品本就不是一回事。

这条边界带来一个让很多工程师不适的结论：放弃企业级统一模型。受「一个数据模型治天下」直觉训练的人，会本能地想把所有「商品」合并成一张表、一个类，再用一堆可空字段和 if (来源 == 库存) 兼容各方。限界上下文反着走——它承认每个上下文有自己的模型，不追求全局唯一，只追求局部一致。两个上下文之间不靠共享类协作，而靠在缝隙处显式翻译（3.4、3.5 节）。代价是多了几套看起来相似的类和一层翻译；收益是每个模型都干净、能独立演化，改 Catalog 的图文结构不会惊动 Inventory。

与下一节的关系：很多人一看到「边界」就联想到微服务、独立部署。但限界上下文的边界比部署边界更早、更基础，下一节先把这两者拆开。

3.3上下文 ≠ 部署 / 微服务边界

限界上下文是模型与语言的边界，它先于微服务存在；在一个单体应用里同样成立，不需要任何独立部署。

底层机制（比定义深一层）：限界上下文是一条逻辑边界——它规定「在这一片代码和语言里，每个术语只有一个含义」。微服务是一条物理边界——它规定「这一块独立部署、独立进程、独立数据库」。逻辑边界先于物理边界：你可以在一个单体里用模块（Java 的包/模块、独立的持久化映射）把 Catalog、Sales、Inventory 干净地隔成三个限界上下文，它们各有各的 Product 类、互不 import 对方的领域对象，仅通过应用层接口或进程内事件协作。这就是一个划好了上下文的模块化单体（modular monolith），一行微服务都没有。

顺序很重要：先有清晰的限界上下文，微服务才可能从边界处自然涌现。如果某个上下文后来确实需要独立伸缩或独立发布，把它从单体里「切」出去成本很低——因为边界早就在那了。反过来，没划清上下文就先拆服务，等于在一团泥里硬切，切出来的服务还在互相调用对方的内部模型，得到的是「分布式单体」：网络开销全有，解耦一点没有。这条线 08 章讲架构时会展开「一个限界上下文 = 一个微服务」为何已被推翻、模块化单体为何优先。

与下一节的关系：五个上下文各自语言自洽之后，它们之间仍要协作——Sales 下单要查 Catalog 的商品、要让 Inventory 预留库存。这些协作关系不能含糊，每条缝隙都得有名字。这就是上下文映射。

3.4上下文映射 Context Map：给每条缝隙命名

上下文映射（Context Map）画出系统里所有限界上下文及它们之间的关系，给每条边界缝隙起一个名字——关系的种类决定了谁迁就谁、翻译在哪一侧、改动如何传播。

底层机制（比定义深一层）：每条关系都隐含一个权力方向（谁是上游 upstream、谁是下游 downstream，上游的改动顺流冲击下游）和一个翻译策略（在边界处翻不翻、谁来翻）。Evans 蓝皮书把常见关系归纳成下面九种。读这张表时，主线是三件事：这是什么关系 → 何时适合用 → 代价是什么。

（这九种里，开放主机服务与发布语言常成对出现；大泥球不是一种"设计"，而是对既有遗留烂摊子的诚实标记——提醒你在边界处用防腐层把混乱挡在外面。）读这张表的关键不是背名字，而是给云市的每条缝隙挑一个。把云市的五个上下文连起来，就得到下面这张上下文映射图。

下一节先把最常用、也最能保护核心域的那条关系——防腐层——讲透。

与下一节的关系：九种关系里，防腐层是核心域保护自己语言的主力武器。Sales 是云市的核心域，它和外部上下文打交道时几乎都该带一层防腐层。下一节钻进去看它具体翻译什么。

3.5防腐层 ACL：在缝隙处显式翻译

防腐层（Anticorruption Layer, ACL）是夹在两个上下文之间的一层翻译，把外部模型转换成本上下文需要的形状，挡住外部概念渗进来腐蚀本地语言。

底层机制（比定义深一层）：防腐层是 Sales 一侧写的一个翻译组件（通常是一个 Translator + 一个本地接口）。它对外调用 Catalog（或 Catalog 的开放主机服务），对内只吐出 Sales 自己的领域对象。外部模型的任何概念都到此为止——Catalog 的 CatalogProduct 永远不会越过这层进入 Sales 的领域代码。下面看翻译的两侧。

// Catalog 上下文对外暴露的「商品」——很胖，且 price 是「当前价」会变
public class CatalogProduct {
    String productId;
    String title;
    List<String> imageUrls;     // Sales 不关心
    String categoryPath;        // Sales 不关心
    String marketingCopy;       // Sales 不关心
    Money  currentPrice;        // 注意：当前价，随时可能调整
}

// Sales 自己的领域对象：下单快照，价格在下单那一刻被冻结
public record OrderLineSnapshot(String productId, String nameSnapshot, Money unitPrice) {}

// 防腐层：唯一允许认识 CatalogProduct 的地方
public class CatalogAcl {
    private final CatalogClient catalog;   // 调外部开放主机服务

    public OrderLineSnapshot snapshotFor(String productId) {
        CatalogProduct ext = catalog.fetch(productId);   // 外部胖对象，到此为止
        // 只取 Sales 需要的三样，并把「当前价」冻结成「单价快照」
        return new OrderLineSnapshot(
            ext.productId,
            ext.title,                  // 翻译：title -> nameSnapshot
            ext.currentPrice            // 翻译：currentPrice -> 冻结的 unitPrice
        );
    }
}

翻译做了三件事，每件都在保护 Sales 的语言：裁剪——丢掉图集、类目、文案这些 Sales 永不使用的字段；改名对齐——Catalog 的 title 进入 Sales 后叫 nameSnapshot，名字落进 Sales 的统一语言；语义冻结——Catalog 的 currentPrice（会变）被翻译成 Sales 的 unitPrice（下单时刻冻结），从此目录改价不再影响这张订单。没有这层，Sales 的 Order 聚合就会直接握着一个会变价、带一堆无关字段的外部对象，「单价快照」这条不变量根本立不住。

与下一节的关系：到这里，五个上下文的内部边界和它们之间的翻译都立住了。但谁来维护这些边界？上下文边界划在哪，最终和团队怎么分有关——这是团队拓扑要回答的。

3.6团队拓扑 Team Topologies：把康威定律反过来用

流对齐团队（stream-aligned team）大致对应一个限界上下文：与其让组织结构无意识地塑造混乱的边界，不如反过来——先想要什么边界，再据此组织团队。

底层机制（比定义深一层）：《团队拓扑 Team Topologies》提出「逆康威调度（inverse Conway maneuver）」——既然组织结构会决定系统边界，那就先设计想要的系统边界，再倒推该如何组织团队。落到云市：让一个流对齐团队完整拥有一个限界上下文（如「下单团队」独占 Sales 的语言、模型、代码和部署），团队边界和上下文边界对齐，团队内部沟通顺畅、跨团队靠明确的上下文映射关系协作。这样康威定律就从「无意识地破坏边界」变成「有意识地强化边界」——团队的自然沟通模式，恰好长出你想要的那条语义边界。

这条线也解释了一个常见的组织级失败模式：当一个「商品」模型由三个团队共同维护，每个团队都只是它的部分股东，没人对整体语言负责，模型就会持续向「谁都能塞字段、谁都不敢删字段」退化。把模型的所有权收拢到单一团队、并让团队边界与上下文边界一致，是从组织层面守住语义边界的根本手段——3.5 节的防腐层守的是代码缝隙，团队拓扑守的是组织缝隙。