L3 - 限界上下文（Bounded Context, BC）

解决方案空间 = BC 的组合——BC 是 Model 的显式边界，是代码 + 团队 + 部署 + 数据库的"垂直切片"。

一句话

Bounded Context = Model 的显式边界 + 物理边界——一个 BC 内，模型语言统一；跨 BC，必翻译。BC 是"垂直切片"不是"水平分层"。

这本书在这一层说了什么

本层融合 IDDD Ch 2 后半 + Ch 4——Vernon BC 深入 + BC 物理体现。

Vernon 原话（BC 边界定义）：

"A Bounded Context is a specific responsibility enforced through a specific model and the physical expression of that model in source code."

Vernon BC 大小论断：

"How long is a piece of string?"

（没有标准答案，但有判断标准）

核心论点 5 个：

BC 是什么（Model + 物理表达）
BC 内不只是 Model（还有 UI / 数据库 / 代码 / 团队）
BC 大小判断标准（业务复杂度 / 团队规模 / 变更频率 / 部署独立性）
BC 与技术组件对齐（包 / 模块 / 部署单元）
Segregated Core 模式（大 BC 切核心）

是什么

1. BC 是什么

Vernon 定义：

"A Bounded Context is a specific responsibility enforced through a specific model and the physical expression of that model in source code."

Vernon 早期反例（SaaSOvation 痛点）：

反例（单 BC 包揽所有）：
  Collaboration BC 包揽：
    - Forum / Post / Discussion（协作概念）
    - User / Permission（身份概念）
    - Calendar / CalendarEntry（日历概念）
    
问题：
  - 模型语义混乱（User 在 Collaboration 里是什么？）
  - "语言学错位"

Vernon 原话（虚构对话）：

"So what if collaboration concepts are tightly coupled to Users and Permissions? We must track who did what!" "In the end, a Forum, a Post, a Discussion, a Calendar, and a Calendar Entry will all be coupled to some kind of human collaborator objects. And that's just it. The linguistics are wrong here." "What we should be focused on are collaboration concepts, such as Author and Moderator. Those are the correct concepts and linguistic terms in a collaboration setting."

教训：不要把 User 当 Author——User 是身份域概念，Author 是协作域概念。

2. BC 不只是 Model（垂直切片）

Vernon 列举 BC 的全部组成：

Bounded Context 包含：
  - Model（领域模型）
  - Sub-domain 的特定切片
  - 代码（Controller / Service / Repository）
  - UI（表现层）
  - 数据库 schema
  - 测试代码
  - 集成代码（与外部系统的接口）

关键洞察：BC 是一个完整的"垂直切片"——从前端到后端到数据库都包含，不是单一"领域层"。

反模式：

❌ "领域层"是 BC → 领域层只是 BC 的一部分
❌ "订单服务"是 BC → 订单服务是 BC 的一种部署形态

3. Subdomain → BC 映射规则

Vernon 映射规则：

Subdomain 数	BC 数	例子
1 个	1 个	SaaSOvation 的 Collaboration BC = 1 个 Subdomain
多个	1 个	电商早期 e-Commerce BC = Product + Orders + Inventory 合并
1 个（复杂）	多个	复杂 Pricing 子域拆成 Pricing Engine + Pricing Rules

Vernon 关键警告（合并多 Subdomain 入 BC）：

"Inside the e-Commerce Bounded Context there are really multiple implicit domain models at play, even though they are not cleanly separated as such. These otherwise separate domain models are actually fused into one software model, and that's very unfortunate."

结论：合并多 Subdomain 入 BC 容易 → 每个 BC 应该模型单一 Subdomain（或紧密相关 Subdomain）。

4. BC 大小判断（Vernon "How long is a piece of string?"）

Vernon 的 4 大判断标准：

1. 业务复杂度
   - 复杂业务 → 更多 BC（每 BC 处理一类业务）
   - 简单业务 → 较少 BC（避免过度拆分）

2. 团队规模
   - 每个团队应有 1-2 个 BC 的所有权
   - Conway 定律：BC 数应与团队数对齐

3. 变更频率
   - 高频变更 → 单独 BC（变更影响隔离）
   - 低频变更 → 可合并（减少协调成本）

4. 部署独立性
   - 需要独立部署 → 单独 BC（独立扩缩容 / 独立发布）
   - 总是同步部署 → 可合并（避免微服务税）

反模式：

❌ 过小 BC：每个实体独立 BC → 微服务税爆炸
❌ 过大 BC：所有业务一个 BC → 强耦合混乱

5. Segregated Core 模式（大 BC 切核心）

Vernon 关键问题：

"How long is a piece of string?"

Vernon 的答案：从场景判断。

场景：大 BC 包揽核心 + 支撑 → 核心被支撑淹没 → 团队焦点失焦。

Segregated Core 模式：把核心能力从大 BC 中"切"出来单独成 BC，支撑能力留在原 BC。

Vernon 原话（时机判断）：

"The time to chop out a Segregated Core is when you have a large Bounded Context that is critical to the system, but where the essential part of the model is being obscured by a great deal of supporting capability."

Segregated Core 案例：

原状态（大 BC）：
  Collaboration BC = 协作核心 + 身份支撑 + 日历支撑
  
问题：
  - 协作核心被支撑淹没
  - 团队焦点失焦
  
Segregated Core 后：
  - Identity BC（独立）
  - Calendar BC（独立）
  - Collaboration BC（聚焦核心）

6. BC 与技术组件对齐

BC 物理体现：

物理形态	适用场景
独立源代码仓库 / 单仓 monorepo 子包	小团队 + BC 数 ≤ 5
独立部署单元（微服务 / JAR）	多团队 + 高变更频率
独立数据库	高隔离 + 独立演化

Vernon 命名建议：

"Always name your Bounded Context."

命名规则：

✅ 用业务能力命名（Collaboration / Identity Access / Agile Project Management）
❌ 不用技术词（Service / Module / System / Engine 除非确实是技术概念）

7. SaaSOvation 三个 BC 详解（Vernon 案例）

Collaboration Context（协作 BC）

职责：协作相关概念

核心 Model：

Forum（讨论版）
Post / Discussion（帖子 / 讨论）
Author / Moderator（作者 / 版主）

关键澄清：

Vernon："What we should be focused on are collaboration concepts, such as Author and Moderator."

Identity and Access Context（身份访问 BC）

职责：用户身份 + 权限管理

核心 Model：

User（用户）
Role（角色）
Permission（权限）
Group（用户组）

Vernon 的"仓鼠问题"：

"You have no locks on your barns and silos, but nobody steals your corn?" "My dog Tumbleweed cares for access management. It's my own silo effect."

教训：身份管理是 Generic Subdomain——用现成 SaaS（Auth0）或独立 BC。

Agile Project Management Context（敏捷 PM BC — 核心域）

职责：Scrum-based Product 管理

核心 Model：

Product（产品）
BacklogItem（待办项）
Task（任务）
Sprint（迭代）
Release（发布）

关键命名澄清：

Vernon 原话： "A Scrum-based Product has any number of BacklogItem instances... This is far different from the products on an e-commerce site that you put in a shopping cart to purchase. How do we know? Because of the Context. We understand what our Product means because it is in the Agile PM Context. In an Online Store Context, Product means something very different."

关键洞察：通用词在不同 BC 有不同含义——Product 在 PM BC ≠ Product 在电商 BC。每 BC 有自己的语言（Ubiquitous Language）。

为什么

为什么 BC 是物理边界不是概念边界？

反例（概念边界但物理共享）：

3 个 BC 共享同一个数据库 → 一改全改
3 个 BC 在同一个部署单元 → 部署阻塞

BC = 物理边界的好处：

独立部署（BC 演化不阻塞其他 BC）
独立团队（Conway 定律反向利用）
独立技术栈（每 BC 选最适合的技术）

Vernon 论断：

"Bounded Context is enforced through a specific model and the physical expression of that model in source code."

为什么通用词在不同 BC 不同含义？

根因 1：模型语义差异

Product 在 PM BC = "软件开发的产品"
Product 在电商 BC = "可购买的商品"
即使名字相同，含义完全不同

根因 2：业务关注点不同

PM BC 关心"产品如何迭代"
电商 BC 关心"产品如何定价"

Vernon 论断：

"We understand what our Product means because it is in the Context."

每 BC 有自己的 Ubiquitous Language——这是 DDD 的核心实践。

为什么 Segregated Core 重要？

场景：大 BC 包揽核心 + 支撑 → 核心被支撑淹没 → 团队焦点失焦。

Segregated Core = 把核心从隐匿中"揭示"。

Vernon 时机判断：

"when you have a large Bounded Context that is critical to the system, but where the essential part of the model is being obscured by a great deal of supporting capability."

怎么做

Step 1：Subdomain → BC 映射

规则：
  1 个 Subdomain → 1 个 BC（默认）
  多个紧密相关 Subdomain → 1 个 BC（合并）
  1 个复杂 Subdomain → 多个 BC（拆分）

Step 2：BC 大小校准

校准维度：
  - 业务复杂度（复杂 → 拆）
  - 团队规模（每团队 1-2 BC）
  - 变更频率（高频 → 拆）
  - 部署独立性（独立部署 → 拆）

Step 3：物理表达 BC

每个 BC 物理化为：
  - 独立源代码仓库 / 独立包
  - 独立部署单元（微服务 / JAR）
  - 独立数据库（可选）
  - 独立团队

命名：用业务能力命名（Collaboration / Pricing Engine / Inventory Service）。

Step 4：识别 Segregated Core 候选

识别信号：
  - 大 BC 包含多个 Subdomain
  - 核心域代码占比 < 50%
  - 团队反馈"核心域代码难找"
  
操作：
  - 切出核心域单独 BC
  - 支撑能力留在原 BC
  - 团队重组（核心域 → 顶级工程师）

Step 5：建立 BC 命名规范

规范：
  - 用业务能力命名（不用技术词）
  - 团队命名一致
  - 上下文映射图标注每个 BC 名称

什么时候用 / 什么时候不用

用 BC 的 2 大场景

场景	关键判断
业务有清晰的语义边界	BC 让每个边界的语言统一
多团队协作 / 需要独立部署	BC 让团队和部署边界清晰

不用 BC（或少量 BC）的 2 大场景

场景	原因
单体业务 + 单团队	BC 是过度拆分
初创期业务快速迭代	BC 划分会变 → 延迟拆分

看不见的地方

失效模式 1：BC 边界 = 技术边界

症状：BC = 一个数据库表 / 一个包 → 业务变化时 BC 不跟着变。

根因：用技术思维划分 BC。

修复：BC 边界对齐业务能力变化（业务变化时 BC 才变化）。

失效模式 2：BC 内融合多个 Subdomain

症状：一个 BC 内有 User 又有 Author → 语义混乱。

根因：未识别 Subdomain 边界。

修复：User → Identity BC，Author → Collaboration BC，BC 间 ACL 翻译。

失效模式 3：BC 过小爆炸

症状：每个实体独立 BC → 微服务税爆炸。

根因：贪图"完全解耦"。

修复：按 Subdomain / 业务能力聚合 BC（不是按实体）。

失效模式 4：未命名 BC

症状：工程师用"订单服务"指代 BC → 业务专家听不懂。

根因：用技术词命名 BC。

修复：用业务能力命名（Order Management / Pricing Engine）。

失效模式 5：核心域被支撑淹没

症状：核心代码在大 BC 中被支撑代码"挤"到角落。

根因：未做 Segregated Core。

修复：识别核心域切出独立 BC。

失效模式 6：BC 间共享数据库

症状：多个 BC 共享同一数据库表 → 强耦合。

根因：图省事。

修复：每 BC 独立数据库 + 集成通过事件/HTTP。

失效模式 7：Segregated Core 误用

症状：把核心域切出来后失去支撑 → 核心域反而更弱。

根因：核心域依赖支撑能力时不能硬切。

修复：先识别核心域依赖，再决定切法。

节点	关联	解释
wonder-04-encounter	强	BC = "照面"的边界——BC 间通过 ACL/事件照面彼此
wonder-05-concealment	中	BC 内部融合多个模型 = "隐匿"——模型语言歧义被掩盖

节点	关联	解释
change-management	强	BC 边界 = 变更边界——一 BC 修改不波及其他
value-stream	中	核心域 BC = 高价值流

层	关系
L2 业务空间	L3 基于 L2 的 Subdomain 划分映射 BC
L4 上下文映射	L4 讲 BC 间关系（基于 L3 的 BC 边界）
L5-L7 战术设计	L5-L7 都在 BC 内（基于 L3 的物理边界）
L8 跨 BC 集成	L8 是 L4 的工程实现

EDM	IDDD L3
Ch 1 一个 BC 一个微服务	L3 BC 物理边界 = 微服务边界
Ch 2 Single Writer	L3 BC 是 Single Writer 的物理边界

状态

L3 概念递进落地完成（融合原书 ch02 后半 + ch04）。

5 个核心论点（BC 定义 / 垂直切片 / Subdomain 映射 / 大小判断 / Segregated Core）
5 步怎么做（映射 / 校准 / 物理化 / Segregated Core / 命名）
7 个失效模式
骨架 A/B + IDDD + EDM + 海德格尔 4 重共振映射

L3 - 限界上下文（Bounded Context, BC） ​

一句话 ​

这本书在这一层说了什么 ​

是什么 ​

1. BC 是什么 ​

2. BC 不只是 Model（垂直切片） ​

3. Subdomain → BC 映射规则 ​

4. BC 大小判断（Vernon "How long is a piece of string?"） ​

5. Segregated Core 模式（大 BC 切核心） ​

6. BC 与技术组件对齐 ​

7. SaaSOvation 三个 BC 详解（Vernon 案例） ​

Collaboration Context（协作 BC） ​

Identity and Access Context（身份访问 BC） ​

Agile Project Management Context（敏捷 PM BC — 核心域） ​

为什么 ​

为什么 BC 是物理边界不是概念边界？ ​

为什么通用词在不同 BC 不同含义？ ​

为什么 Segregated Core 重要？ ​

怎么做 ​

Step 1：Subdomain → BC 映射 ​

Step 2：BC 大小校准 ​

Step 3：物理表达 BC ​

Step 4：识别 Segregated Core 候选 ​

Step 5：建立 BC 命名规范 ​

什么时候用 / 什么时候不用 ​

用 BC 的 2 大场景 ​

不用 BC（或少量 BC）的 2 大场景 ​

看不见的地方 ​

失效模式 1：BC 边界 = 技术边界 ​

失效模式 2：BC 内融合多个 Subdomain ​

失效模式 3：BC 过小爆炸 ​

失效模式 4：未命名 BC ​

失效模式 5：核心域被支撑淹没 ​

失效模式 6：BC 间共享数据库 ​

失效模式 7：Segregated Core 误用 ​

相关节点 ​

骨架 A — 世界观 ​

骨架 B — 工程实践 ​

与 IDDD 其他层对位 ​

与 EDM 对位 ​

与海德格尔对位 ​

状态 ​

L3 - 限界上下文（Bounded Context, BC）

一句话

这本书在这一层说了什么

是什么

1. BC 是什么

2. BC 不只是 Model（垂直切片）

3. Subdomain → BC 映射规则

4. BC 大小判断（Vernon "How long is a piece of string?"）

5. Segregated Core 模式（大 BC 切核心）

6. BC 与技术组件对齐

7. SaaSOvation 三个 BC 详解（Vernon 案例）

Collaboration Context（协作 BC）

Identity and Access Context（身份访问 BC）

Agile Project Management Context（敏捷 PM BC — 核心域）

为什么

为什么 BC 是物理边界不是概念边界？

为什么通用词在不同 BC 不同含义？

为什么 Segregated Core 重要？

怎么做

Step 1：Subdomain → BC 映射

Step 2：BC 大小校准

Step 3：物理表达 BC

Step 4：识别 Segregated Core 候选

Step 5：建立 BC 命名规范

什么时候用 / 什么时候不用

用 BC 的 2 大场景

不用 BC（或少量 BC）的 2 大场景

看不见的地方

失效模式 1：BC 边界 = 技术边界

失效模式 2：BC 内融合多个 Subdomain

失效模式 3：BC 过小爆炸

失效模式 4：未命名 BC

失效模式 5：核心域被支撑淹没

失效模式 6：BC 间共享数据库

失效模式 7：Segregated Core 误用

相关节点

骨架 A — 世界观

骨架 B — 工程实践

与 IDDD 其他层对位

与 EDM 对位

与海德格尔对位

状态