L2 - 业务空间（Domain / Subdomain）

业务空间 = 业务的"自然语言"划分——业务是什么、怎么分解、什么是核心。这是 DDD 战略设计的第一步。

一句话

业务空间（问题空间）= 业务全景（Domain）= 子域（Subdomain）的组合。子域类型决定资源投入：核心域最高、通用域买现成。

这本书在这一层说了什么

本层融合 IDDD Ch 2 前半——Vernon 三大定义 + 业务空间划分 + 核心域识别。

Vernon Ch 2 三件必懂的事：

"There are three things you are going to have to understand very clearly: • What your Domain is • What your Subdomains are • What your Bounded Contexts are"

Vernon 对 Evans 的延伸：

"Just because all these concepts were discussed in detail in the second half of [Evans] does not mean that they are of secondary importance. To succeed in implementing DDD, you have to get these right."

核心论点 3 个：

1. Domain = 业务全景（"what an organization does and the world it does it in"）
2. Subdomain = 业务自然分解（电商：Product Catalog / Orders / Invoicing / Shipping / Inventory）
3. 核心域识别：Core / Supporting / Generic 三类型 → 资源分配

是什么

1. Domain（域）

Vernon 定义：

"A Domain, in the broad sense, is what an organization does and the world it does it in."

Vernon 提醒"Domain"一词重载：

• 广义 = 整个业务域
• 狭义 = 一个核心域/支撑域

读 IDDD 时按上下文区分。Vernon 在用狭义时会明确加 Core Domain / Subdomain 限定。

判断：你在哪个 Domain 工作？业务专家一眼能告诉你。

2. Subdomain（子域）

Vernon 定义：

"The whole Domain of the organization is composed of Subdomains."

Vernon 电商例：

电商业务域 = 5 个 Subdomain：

• Product Catalog（产品目录）
• Orders（订单）
• Invoicing（发票）
• Shipping（运输）
• Inventory（库存）

关键洞察：子域是业务的"自然语言"分解——业务专家认可，无需技术解释。

3. 三种 Subdomain 类型

类型	含义	投资策略	例子
Core Domain（核心域）	业务核心竞争力	最高投入	电商的 Pricing/Recommendation
Supporting Subdomain（支撑域）	支撑核心的业务能力	中等投入	电商的 Inventory
Generic Subdomain（通用域）	通用能力	最低投入（可买 SaaS）	电商的 Email/Auth

Vernon 核心域定义：

"The Core Domain is the reason the software is being written."

Vernon 资源分配：

"Your aim should be to maximize investment in the Core Domain, while minimizing investment in Supporting and Generic Subdomains."

4. 为什么 Subdomain 是"自然分解"

Vernon 论断：

"Each business function represents a Subdomain."

业务的"做什么" = 业务功能清单。每功能 = 一个 Subdomain。

反模式：

• ❌ 按技术分层划分（OrderService / OrderRepository / OrderController 都是同一子域）
• ❌ 按组织划分（每个团队一个子域）—— 团队随业务调整，子域不应该跟着变

为什么

为什么业务空间要先于解决方案空间？

业务空间 = 业务专家的语言（子域） 解决方案空间 = 工程师的语言（BC）

必须先业务后方案的根因：

• 业务变化慢（业务核心能力相对稳定）
• 方案变化快（技术栈演化、团队调整）
• 混在一起 → 业务变化被技术细节拖慢

Vernon 警告：

"Designing without strategic design hurts."

无业务空间划分的代价：

• 模型混乱（Big Ball of Mud）
• 变更蔓延（一改全改）
• 团队冲突（Conway 定律反转）

为什么核心域要最高投入？

Vernon 论断：

"The Core Domain is the reason the software is being written."

根因：核心域 = 业务差异化 = 公司活下去的理由。

• 通用域（Email/Auth）→ 买现成（差异化 = 0）
• 支撑域（Inventory）→ 中等投入（差异化低）
• 核心域（Pricing/Recommendation）→ 最高投入（差异化高）

资源分配的逻辑：把最好的工程师放在核心域。

为什么通用域要买现成？

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."

根因：身份管理是通用能力——每个 BC 都自己造身份 = 重复造轮子 + 安全隐患。

修复：Identity 是典型的 Generic Subdomain——用现成的 SaaS（如 Auth0）或独立 BC。

怎么做

Step 1：与业务专家工作坊（识别子域）

操作：
  1. 邀请业务专家（不是技术经理）
  2. 让业务专家列出"业务做什么"
  3. 每项业务功能 = 一个候选 Subdomain
  4. 标记每个 Subdomain 的类型（Core / Supporting / Generic）
  
产出：
  - Subdomain 清单（带类型）
  - 业务能力地图

Vernon 关键技巧：用业务专家的原话命名 Subdomain，不用技术翻译。

Step 2：核心域识别决策树

决策树：
  Q1: 没有这个能力业务还成立吗？
    否 → Core Domain（最高投入）
    是 ↓
  Q2: 这个能力业务差异化在哪？
    否 → Generic Subdomain（买现成）
    是 → Supporting Subdomain（中等投入）

Step 3：业务能力地图（可视化）

电商业务能力地图（Vernon 例）：
  [Core] Pricing Engine（定价引擎）
    ├─ [Supporting] Product Catalog（产品目录）
    ├─ [Supporting] Orders（订单）
    │   └─ [Supporting] Inventory（库存）
    ├─ [Generic] Invoicing（发票，用 SaaS）
    ├─ [Supporting] Shipping（运输）
    └─ [Generic] Email（邮件，用 SaaS）

Step 4：Subdomain → BC 映射

映射规则：

• 一个 Subdomain → 一个 BC（典型）
• 多个紧密相关 Subdomain → 一个 BC（合并）
• 一个复杂 Subdomain → 多个 BC（拆分）

详见 L3 - 限界上下文（BC）。

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

用业务空间划分的 2 大场景

场景	关键判断
业务复杂度 ≥ 3 个子域	必须业务空间划分，否则就是 Big Ball of Mud
业务战略不清晰，需要聚焦核心	业务空间划分强制审视核心域

不做业务空间划分的 2 大场景

场景	原因
单体业务 + 单团队 + 简单 CRUD	业务空间划分是过度工程
初创期业务未稳定	子域划分会反复变 → 等稳定再做

看不见的地方

失效模式 1：Domain/Subdomain/BC 三概念混用

症状：团队讨论"BC"时实际指的是"Subdomain"，或反之。

根因：三概念确实关联紧密，但作用空间不同。

检测：问"这是描述业务还是描述代码？"——业务 = Subdomain，代码 = BC。

修复：严格区分。业务讨论用 Subdomain，代码讨论用 BC。

失效模式 2：核心域识别错误

症状：把通用域（Auth/Email）当核心域投入大量资源 → ROI 差。

根因：业务战略不清晰，无法判断核心域。

修复：先做业务战略分析（核心竞争力在哪？）。

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

症状：核心域和支撑域在同一个 BC → 核心域被支撑代码"挤"到角落。

根因：未做 Segregated Core。

修复：参考 L3 中 Segregated Core 模式，把核心从支撑中切出。

失效模式 4：通用域自造

症状：每个团队都自己造身份管理 / 邮件服务 → 重复造轮子 + 安全漏洞。

根因：未识别通用域。

修复：通用域必须买 SaaS 或独立 BC 共享。

失效模式 5：业务专家缺席建模

症状：开发闭门造车 → 子域划分技术化（按数据库表）→ 业务专家看不懂。

根因：未邀请业务专家参与。

修复：建模工作坊必须业务专家参与。

相关节点

骨架 A — 世界观

节点	关联	解释
wonder-01-emergence-vision	强	子域 = "涌现视域"的业务划分——业务空间本身是涌现的整体

骨架 B — 工程实践

节点	关联	解释
value-stream	强	核心域 = 高价值流，通用域 = 低价值流——资源分配对齐价值
metrics-improvement	中	子域类型分布是战略度量：核心域占比应反映业务战略

与 IDDD 其他层对位

层	关系
L1 入门	建立在 L1 "为什么 DDD" 之上
L3 限界上下文	L2 解决"业务怎么分"，L3 解决"代码怎么分"
L4 上下文映射	BC 间关系基于 L2/L3 的子域 / BC 划分

与 EDM 对位

EDM	IDDD L2
Ch 1 一个 BC 一个微服务	L2 一个 Subdomain → 一个 BC（典型）

状态

L2 概念递进落地完成（融合原书 ch02 前半 + 部分 ch04）。

• 4 个核心论点（Domain / Subdomain / 三类型 / 自然分解）
• 4 步怎么做（工作坊 / 决策树 / 地图 / 映射）
• 5 个失效模式
• 骨架 A/B + IDDD + EDM 完整映射