第2章 业务维度边界划分：限界上下文、业务能力对齐、子域划分、核心域/支撑域/通用域

业务维度的边界划分是组件拆分的起点。如果不能从业务领域正确识别限界上下文、对齐业务能力、划分子域、区分域类型，后续的技术实现将陷入“为拆分而拆分”的泥潭。本章聚焦如何从业务模型推导出清晰的组件边界。

2.1 核心概念与关系

DDD（领域驱动设计）中的四个核心概念构成了业务维度划分的层层递进关系：

• 限界上下文（Bounded Context） — 业务逻辑的显式边界，内部维护统一语言和模型完整性。
• 业务能力（Business Capability） — 组织/系统实现某一业务目标的能力集合，常与限界上下文形成“能力→上下文”映射。
• 子域（Subdomain） — 业务领域的问题空间细分，每个子域对应一个或多个限界上下文。
• 域类型 — 将子域分为核心域（竞争优势）、支撑域（必需但非核心）、通用域（标准化可采购）。

2.2 业务维度边界划分四步流程

2.3 限界上下文与业务能力对齐矩阵

以下示例展示一个电商平台的“订单管理”限界上下文如何与业务能力对齐：

2.4 子域划分与域类型决策

子域划分不是简单的功能模块拆分，而是基于业务价值的战略化分层：

• 核心域 — 公司拥有差异化竞争力的领域，组件应内聚、高自治、强内聚，避免过早抽象。
• 支撑域 — 业务必需但非差异化，组件可适度耦合或依赖成熟框架，但需保留扩展点。
• 通用域 — 市场已有成熟方案，优先引入 SaaS 或开源组件，内部仅做适配层，避免自研。

2.5 业务维度边界划分流程图

2.6 选型权衡与风险点

2.7 落地步骤

1. 第1步（1~2周）：与业务方、产品、领域专家共同进行事件风暴，产出领域事件流和聚合初稿。
2. 第2步（1周）：基于聚合和业务能力，画出上下文映射图，标注合作者关系、共享内核、分离方式。
3. 第3步（1周）：将每个限界上下文标记域类型，并决定各域的治理策略、技术选型（如核心域用CQRS/ES，通用域用REST）。
4. 第4步（持续）：在迭代中通过“领域知识侵蚀检测”定期review模型是否偏离限界上下文边界。

2.8 验收标准

• 完整性：每个业务能力都唯一对应一个限界上下文，不存在“没有归属”的能力。
• 正交性：任意两个限界上下文之间的依赖关系清晰（合作者/遵奉者/分离方式），无循环依赖。
• 域类型收敛：核心域数量不超过总子域数的30%，通用域占比不低于20%。
• 变更影响：修改一个限界上下文内部模型时，不影响超过两个其他上下文。