摘要：同样叫"商品"，在商品、库存、订单、促销里可能根本不是同一个模型。本章用这个最容易踩坑的例子讲清限界上下文和统一语言：模型必须有边界，语言必须在边界内保持稳定。读完后，你能区分"子域是问题空间，限界上下文是解空间"。

先讲一个真实的困惑："商品"到底是什么

在"优选门店"里，问不同部门同一个词："商品"。

• • 商品管理部门说：商品就是 SPU/SKU，有标题、图片、类目、规格、品牌。
• • 库存部门说：商品就是仓库里那个有数量、有库位的东西，我不关心它图片好不好看。
• • 订单部门说：商品就是下单那一刻的一个快照——名称、单价、数量，成交后图片改了价格变了都跟这张订单无关。
• • 促销部门说：商品就是一个能打折、能参加满减的计价单位。

同一个词"商品"，在四个部门里指的根本不是同一个东西。

传统做法会怎么干？建一张大而全的 product 表，把所有部门要的字段都塞进去，全公司共用一个 Product 类。结果：

• • 这个 Product 类有 50 多个字段，库存的同事看不懂一半。
• • 改商品图片字段，结果订单模块的代码编译不过——因为大家共用一个类。
• • 谁都能改这个类，谁都不敢改这个类。

这就是没有"限界上下文"的下场。

大白话：限界上下文是什么

限界上下文 = 一个明确的边界，在这个边界内，每个术语只有一个清晰、唯一的含义。

"界"是边界，"限"是限定。它限定了一套领域模型（和它的术语）的适用范围。

回到"商品"的例子：我们划出四个限界上下文，每个上下文里的"商品"是不同的模型：

【商品上下文】          【库存上下文】         【订单上下文】          【促销上下文】
 Product               StockItem             OrderItem             PromotionItem
 - 标题/图片/类目        - SKU编号             - 商品名称(快照)        - 计价单位
 - 规格/品牌            - 可用数量             - 成交单价(快照)        - 可打折标记
 - 上架状态             - 库位                - 数量
                       - 锁定数量

每个上下文里的模型，只为自己上下文的职责服务，互不干扰。库存上下文根本没有"图片"这个概念，订单上下文里的价格是下单那一刻"冻结"的快照。

类比：同一个词"苹果"，在水果店指水果，在数码店指手机。"水果店"和"数码店"就是两个限界上下文。脱离上下文谈"苹果是什么"没有意义。

原理图：为什么一个大模型会失控

新手要记住：重复类名不一定是坏事，共享错误模型才是坏事。 Catalog.Product 和 Order.OrderItem 看似都和商品有关，但它们关心的业务事实不同，就应该分开。

统一语言（Ubiquitous Language）

限界上下文的"边界内"，要靠统一语言来保证术语一致。

统一语言 = 在一个限界上下文内，业务人员、产品、开发、测试，以及代码本身，全都用同一套术语，且含义完全一致。

这意味着：

• • 产品说"冻结优惠券"，代码里就该有 coupon.freeze()，而不是 couponMapper.updateStatus(id, 2)。
• • 业务说"订单待支付"，代码里订单状态就叫 PENDING_PAYMENT，不是 status = 0。
• • 需求文档、数据库表、Java 类名、方法名，全部对齐同一套词汇。

为什么这么做？好处是什么？

1. 1. 消灭翻译损耗：没有统一语言时，业务说一套、文档写一套、代码又是一套，每次需求都要在三套语言间"翻译"，一翻译就丢信息、就出 bug。统一语言让"业务怎么说，代码就怎么写"。
2. 2. 代码自解释：order.cancel()、coupon.freeze() 这样的代码，业务人员都能看个大概，新人上手快。
3. 3. 建模即沟通：开会讨论术语的过程，本身就是在澄清业务规则。很多业务理解上的分歧，会在"这个词到底什么意思"的争论中暴露出来。

对比传统做法的弊端

传统项目里，数据库字段叫 f_status、type1、flag，方法叫 doProcess()、handle2()。业务语言和代码语言完全是两个世界。三个月后写代码的人自己都忘了 status=2 是什么意思，只能去翻代码、问人，效率极低且极易出错。

限界上下文 vs 子域：到底啥关系

新手最容易混。一句话区分：

子域是"问题空间"的划分（业务上有哪些事要做），限界上下文是"解空间"的划分（软件上怎么建模和切分）。

更白话一点：

子域是业务地图，限界上下文是代码地图。子域告诉你业务有哪些块，限界上下文告诉你这些块在软件里怎么建模、怎么隔离。

比如"优选门店"从业务上看有商品、库存、订单这些子域；但落到代码里，"商品"这个词不能全系统共用一个万能 Product：

场景	在这个上下文里，"商品"真正关心什么
商品上下文	标题、图片、类目、规格、上下架状态
库存上下文	SKU、库位、可用库存、锁定库存
订单上下文	下单那一刻的商品名、成交价、购买数量

所以再压缩成一句：子域偏"业务分类"，限界上下文偏"模型边界"。

理想情况下，一个子域对应一个限界上下文（一一对应最清晰）。但现实中也可能：

• • 一个大子域拆成多个上下文；
• • 历史遗留系统里，一个上下文横跨了多个子域（不理想，但常见）。

对"优选门店"，我们采用清晰的一一对应：

子域（业务视角）	限界上下文（软件视角）
订单交易（核心）	订单上下文 Order Context
促销（核心）	促销上下文 Promotion Context
商品（支撑）	商品上下文 Catalog Context
库存（支撑）	库存上下文 Inventory Context
会员（支撑）	会员上下文 Member Context
支付（通用）	支付上下文 Payment Context
配送（支撑）	配送上下文 Delivery Context