📚 课程目录第4章子域划分策略

4. 子域划分策略：核心子域、支撑子域、通用子域的定义与识别方法

在领域驱动设计（DDD）的战略设计中，将问题空间（Problem Space）划分为若干子域（Subdomain）是服务边界划分的第一步。子域并非技术概念，而是业务视角下的逻辑分区。根据业务价值与独特性，子域被划分为三种类型：核心子域、支撑子域与通用子域。准确识别这三类子域，是决定微服务投资优先级、团队组织方式以及技术选型的核心依据。

4.1 三类子域的定义与特征

类型	定义	业务价值	独特性	复杂度	典型示例（电商）
核心子域	企业实现战略差异化、获得竞争优势的关键业务领域。	极高，直接决定企业核心竞争力	高度独特，行业内无标准解决方案	高，需要深度定制与持续创新	商品推荐引擎、定价策略、风控模型
支撑子域	支撑核心业务运转，但本身不构成竞争优势的领域。	中等，必不可少但非差异化	有一定独特性，但可借鉴行业实践	中，通常需要定制开发	订单管理、库存管理、用户账户
通用子域	几乎所有企业都需要的、有成熟现成方案的领域。	低，不产生差异化价值	无独特性，行业标准方案成熟	低，可采购或使用开源方案	身份认证、邮件通知、日志审计

  关键原则：核心子域应投入最优质的资源进行自研与持续优化；支撑子域可适度定制，但避免过度投资；通用子域应优先采购或复用开源方案，绝不自行重复造轮子。

4.2 识别方法：三步定位法

识别三类子域并非凭直觉判断，而是通过系统化的业务分析逐步收敛。推荐采用以下三步定位法：

业务价值排序：与业务方共同梳理所有业务能力，按“对营收/战略目标的影响程度”从高到低排序。排名前20%且不可替代的，初步标记为核心候选。
独特性评估：针对每个候选子域，回答“如果购买现成软件或使用开源方案，能否满足80%以上的需求？”若答案为“是”，则排除核心子域，归入通用或支撑。
替代成本分析：对于非核心候选，评估“替换为外部方案的成本与风险”。替换成本低且风险小的，归为通用子域；替换成本高或风险大的，归为支撑子域。

实践提示：在识别过程中，务必邀请业务专家与领域专家共同参与。技术团队容易高估通用子域的独特性，而业务方则可能低估支撑子域的重要性。跨角色协作是准确识别的保障。

4.3 子域类型与微服务策略映射

不同类型的子域，在微服务架构中的实现策略截然不同。下表总结了关键差异：

维度	核心子域	支撑子域	通用子域
开发模式	自研，内部团队主导	自研或合作开发	采购SaaS / 开源集成
团队组织	独立全功能团队，高自治	独立团队，适度自治	平台团队或外包维护
技术投入	最高优先级，持续重构	中等优先级，按需迭代	最低优先级，保持稳定
服务粒度	较细，可拆分为多个服务	适中，通常一个子域一个服务	较粗，尽量复用外部服务
变更频率	高，持续演进	中，随业务需求变化	低，版本升级为主

4.4 子域划分与限界上下文的关联

子域属于问题空间，而限界上下文（Bounded Context）属于解决方案空间。一个子域可以对应一个或多个限界上下文，但通常建议保持一对一的映射关系，以降低跨上下文通信的复杂度。下图展示了从业务子域到微服务边界的典型映射过程：

4.5 常见识别误区与避坑指南

误区一：将技术复杂度等同于核心价值。
例如，一个高并发的日志收集系统，技术上很复杂，但如果它不直接产生业务差异化，应归为通用子域，而非核心子域。核心子域的判断标准是业务独特性与战略价值，而非技术挑战。

误区二：所有子域都自研微服务。
对于通用子域（如邮件、短信、支付网关），自行开发微服务不仅浪费资源，还会增加维护负担。正确的做法是采购SaaS或集成开源方案，仅在必要时通过防腐层（Anti-Corruption Layer）进行适配。

误区三：子域划分一成不变。
随着业务发展，支撑子域可能升级为核心子域（例如，当企业决定将物流能力作为差异化竞争点时），通用子域也可能因监管要求而变为支撑子域。子域划分应定期复盘，保持动态调整。

4.6 子域识别清单（快速自检）

在实际项目中，可以使用以下清单快速判断每个候选子域的类型：

判断问题	是 → 倾向类型	否 → 倾向类型
该领域是否直接决定企业的市场竞争力？	核心子域	支撑或通用
行业内是否有成熟的商业软件或开源方案？	通用子域	核心或支撑
如果停止该领域的功能，业务是否立即瘫痪？	核心或支撑	通用子域
该领域是否需要频繁变更以适应市场变化？	核心子域	支撑或通用
外部方案能否满足80%以上的需求？	通用子域	核心或支撑

推荐实践：在项目启动阶段，组织一次“子域划分工作坊”，使用上述清单对业务能力逐一打分。将结果可视化到一张“业务价值-独特性”矩阵图上，可以更直观地识别出三类子域的边界。