限界上下文

学习目标

• 能解释“限界上下文”如何为一个模型和一套通用语言划定明确适用范围，并在边界外通过翻译维护各自模型完整性
• 能逐项定位 限界上下文、显式边界、持续集成、翻译、局部通用语言，并说明每个概念在当前来源边界内承担什么责任
• 能按 发现术语冲突 → 声明上下文 → 指定模型所有者 → 设计翻译 → 持续集成验证 推演“客户含义冲突”，检查“上下文内部术语含义一致且持续集成，跨上下文数据必须经过显式映射或协议”
• 能注入“以微服务数量、代码仓库或数据库 schema 自动代替模型边界”，依据上下文名称、语言词典、所有者、边界接口、翻译映射、集成测试与模型冲突记录定位越界、撤销并用同一情境重放

为什么从“先以模型含义是否能够保持一致来划界，再决定团队、部署和数据所有权如何配合这个边界”开始

为一个模型和一套通用语言划定明确适用范围，并在边界外通过翻译维护各自模型完整性。本页先画责任和依赖，再沿具体情境执行决策，最后主动制造一个边界违规；这种顺序把术语变成可以验证、推翻和恢复的设计合同。

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

来源、版次与课程边界

限界上下文、持续集成与上下文间翻译以 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：核对分层、限界上下文、战术模式和上下文映射的公开摘要正文

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

核心概念与可观察责任

限界上下文

限界上下文明确一个模型在哪些条件和范围内适用，范围外即使使用同一个词，也不能自动继承相同含义。 在“客户含义冲突”中，观察重点是上下文内部术语含义一致且持续集成，跨上下文数据必须经过显式映射或协议。

显式边界

边界要能在团队责任、代码入口、数据交换和运行接口上被看到；模糊边界会让模型在不知不觉中混合。 在“仓库共用”中，观察重点是上下文名称、语言词典、所有者、边界接口、翻译映射、集成测试与模型冲突记录。

持续集成

同一上下文内的成员频繁合并并验证模型一致性，尽早发现两套含义正在分叉，而不是等到发布时才整合。 在“客户含义冲突”中，观察重点是上下文内部术语含义一致且持续集成，跨上下文数据必须经过显式映射或协议。

翻译

跨上下文协作时，把外部消息映射为本地模型可理解的含义；翻译既保护本地语言，也明确不可无损转换的部分。 在“仓库共用”中，观察重点是上下文名称、语言词典、所有者、边界接口、翻译映射、集成测试与模型冲突记录。

局部通用语言

通用语言只在上下文内通用，同名术语可以在其他上下文拥有不同属性和生命周期，这不是重复，而是明确语境。 在“客户含义冲突”中，观察重点是上下文内部术语含义一致且持续集成，跨上下文数据必须经过显式映射或协议。

一条可执行的设计判断

本页采用以下判断链：先以模型含义是否能够保持一致来划界，再决定团队、部署和数据所有权如何配合这个边界。正常情况下必须持续保持“上下文内部术语含义一致且持续集成，跨上下文数据必须经过显式映射或协议”；反例“以微服务数量、代码仓库或数据库 schema 自动代替模型边界”只改变一个关键条件，便于定位因果。

观察项	本页合同
最小正常情境	订单关心收货资料，风控关心主体与风险关系
边界或迁移情境	两个团队共用代码仓库但业务语言完全不同
必须保持	上下文内部术语含义一致且持续集成，跨上下文数据必须经过显式映射或协议
首要违规	以微服务数量、代码仓库或数据库 schema 自动代替模型边界
验收证据	上下文名称、语言词典、所有者、边界接口、翻译映射、集成测试与模型冲突记录

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

⚡分步1 / 3

1. 1
2. 2
3. 3

实验一：边界与模型地图

操作前先预测“客户含义冲突”里哪一侧拥有规则、哪一侧只是技术或协作细节。切换概念和情境后，检查“先以模型含义是否能够保持一致来划界，再决定团队、部署和数据所有权如何配合这个边界”是否仍能解释三块区域的责任。

Boundary model

限界上下文：边界与责任地图

为一个模型和一套通用语言划定明确适用范围，并在边界外通过翻译维护各自模型完整性

切换最小情境

客户含义冲突仓库共用

定位正式概念

限界上下文显式边界持续集成翻译局部通用语言

architecturedomaindesign-07 · 当前观察

限界上下文：订单关心收货资料，风控关心主体与风险关系

区域 1订单上下文

客户是下单与履约参与者

↓

区域 2翻译边界

映射身份、状态和允许的语义损失

↓

区域 3风控上下文

客户是被评估的风险主体

情境验收

分别建模并在边界映射标识，不共享一个不断膨胀的 Customer

上一步重置播放下一步

易错边界与取舍

练习与答案

练习

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

1. 限界上下文：写出它所在的边界、允许的依赖方向、一个最小反例和一份可观察证据。
2. 显式边界：写出它所在的边界、允许的依赖方向、一个最小反例和一份可观察证据。
3. 持续集成：写出它所在的边界、允许的依赖方向、一个最小反例和一份可观察证据。
4. 翻译：写出它所在的边界、允许的依赖方向、一个最小反例和一份可观察证据。
5. 局部通用语言：写出它所在的边界、允许的依赖方向、一个最小反例和一份可观察证据。

查看答案

对每个概念先确定它属于业务政策、模型协作还是外部技术，再画允许的依赖方向。用“订单关心收货资料，风控关心主体与风险关系”建立正常基线，用“以微服务数量、代码仓库或数据库 schema 自动代替模型边界”作为单一反例，最后从上下文名称、语言词典、所有者、边界接口、翻译映射、集成测试与模型冲突记录中找第一处不一致。

问题 2：最小情境推演。 怎样验证“客户含义冲突”没有靠最终功能碰巧通过？

查看答案

按 发现术语冲突 → 声明上下文 → 指定模型所有者 → 设计翻译 → 持续集成验证 保存每步状态，预期结果是“分别建模并在边界映射标识，不共享一个不断膨胀的 Customer”。最终输出之外，还要逐步确认“上下文内部术语含义一致且持续集成，跨上下文数据必须经过显式映射或协议”；任一中间状态越界都应拒绝当前设计。

问题 3：替代方案与恢复。 注入“以微服务数量、代码仓库或数据库 schema 自动代替模型边界”后，怎样比较修复与更简单方案？

查看答案

先保留故障前的上下文名称、语言词典、所有者、边界接口、翻译映射、集成测试与模型冲突记录，再记录首个越界位置。分别实施最小修复和删除多余模式的方案，用同一个“两个团队共用代码仓库但业务语言完全不同”重放；选择仍满足“仓库不是模型边界证据，仍需显式上下文和翻译合同”且依赖更少的方案。

本页小结

• 限界上下文的核心判断是：先以模型含义是否能够保持一致来划界，再决定团队、部署和数据所有权如何配合这个边界。
• 正常路径以“分别建模并在边界映射标识，不共享一个不断膨胀的 Customer”验收，不能只检查接口返回成功。
• 边界路径以“仓库不是模型边界证据，仍需显式上下文和翻译合同”验收，并保存上下文名称、语言词典、所有者、边界接口、翻译映射、集成测试与模型冲突记录。
• 如果“以微服务数量、代码仓库或数据库 schema 自动代替模型边界”仍可静默通过，说明边界只是图示，没有成为可执行约束。