限界上下文是什么
限界上下文是模型一致性的边界：边界内每个术语只有一种含义，模型不需要额外限定词就能表达清楚；边界外允许出现同名但含义不同的概念。它由业务语义划分，通常与团队边界、服务边界和部署单元对齐，但并不等于子系统——子系统按技术或功能划分，限界上下文按模型语义划分。识别上下文是拆服务与划分模块的前置工作。
基本信息
| 核心判据 | 同一术语在边界内含义一致，无需加限定词解释 |
|---|---|
| 与子系统区别 | 子系统按技术或功能划分，限界上下文按模型语义划分 |
| 常见对齐 | 常与微服务边界、代码模块边界、团队边界一致 |
| 识别手段 | 事件风暴、术语冲突点分析、组织结构与变更频率观察 |
| 产出物 | 上下文清单、上下文映射图、每个上下文的通用语言术语表 |
上下文映射关系
| 模式 | 关系说明 | 典型场景 |
|---|---|---|
| 合作关系 | 两个上下文共同演进、协调发布 | 联系紧密、目标一致的团队之间 |
| 客户-供应商 | 下游依赖上游，需求方向单向 | 中台与业务线之间 |
| 防腐层 | 下游加转换层隔离上游模型 | 集成遗留系统或外部供应商 |
| 共享内核 | 共享小范围且稳定的模型 | 公共概念与基础类型 |
| 遵奉者 | 下游完全沿用上游模型，不做转换 | 上游强势且模型通用时 |
| 各行其道 | 不做集成，各自独立演进 | 集成收益低于成本时 |
典型使用场景
- 拆分服务前：先划清语义边界，避免按技术层切分
- 术语冲突治理：同一词在不同团队含义不同，说明存在边界或需要裁决
- 团队划分依据：让团队边界与语义边界尽量重合，减少协调成本
- 集成方案设计：为上下游关系选择映射模式并落地防腐层
- 遗留系统改造：识别现有模块实际承载的上下文，找到混装区域
- 需求评审：发现同一需求跨多个上下文时，先确认哪一方承担规则
上下文映射不只有技术含义，也反映组织关系：供应商模式往往对应强势上游团队，合作关系则要求双方发布节奏同步。
边界划分过细会产生大量跨上下文调用与集成成本，划得过粗则模型含义被稀释，需要结合团队结构与变更频率综合权衡。