领域驱动战略：解密子域（Core/Supporting/Generic Subdomain）划分红线与资源调配策略

在企业进行大型复杂系统微服务架构重构时，开发团队面临的最大阻碍通常是“胡子眉毛一把抓”：将有限的研发人力平均分配到整个软件系统的几百个业务模块上，导致最核心的商业壁垒业务（如交易系统的撮合引擎）由于人手不足而千疮百孔，而边缘业务（如后台短信发送、基础权限管理）却被过度设计。

为了帮助企业理清商业竞争的核心资产，领域驱动设计（DDD） 提出了核心战略规划工具——**子域（Subdomain）** 拆分与资源调配模型。

本文将系统拆解核心域、支撑域与通用域的划分红线，以及如何在微服务建设中进行研发资源的战略倾斜。

一、 问题空间的三大子域划分模型

在 DDD 战略设计中，我们首先将业务问题空间（Problem Space）划分为三个具有不同商业竞争价值的子域：

二、 战略寻址：子域与限界上下文的物理映射

理解了子域的分类后，我们需要在物理层面将子域与微服务限界上下文（Bounded Context）进行科学映射： [ 企业全局业务问题空间 (Problem Space) ] │ ┌──────────────────┼──────────────────┐ ▼ (商业核心壁垒) ▼ (辅助支撑业务) ▼ (全行业通用标准) [ 核心域 (Core) ] [ 支撑域 (Supporting) ] [ 通用域 (Generic) ] │ │ │ ▼ ▼ ▼ [ 限界上下文 A ] [ 限界上下文 B ] [ 限界上下文 C ] (自主研发/高资源) (自主研发/按需分配) (直接购买 SaaS / 开源)

在理想状态下，一个子域应当物理对应一个限界上下文（微服务）。但在遗留系统重构中，往往存在一个巨大的“大单体”，它内部同时混合着核心域（如交易）和通用域（如发信），这正是重构微服务拆分的突破口。

三、 研发资源倾斜与落地防御红线

划分出子域的核心目的，是**指导 CTO 与架构师进行研发资源的战略调配**。架构团队必须坚守以下三条战略红线：

1. 研发资源倾斜红线：将 70% 黄金资源投向核心域

核心域必须由公司最顶尖的架构师和业务专家组成联合攻关小组进行自主研发，确保其代码模型的高度内聚与高灵活性。支撑域与通用域则采用外包、初级研发团队、或直接集成第三方开源框架的形式快速落地，腾出黄金人力。

2. 技术适配器防御红线：以防腐层（ACL）隔离通用域

通用域（如第三方微信支付）往往提供杂乱无章的接口协议。核心域如果直接调用通用域，核心模型就会受到污染。必须在核心域中设立 ACL（防腐层），阻断通用域的坏味道穿透入核心域。

四、 总结

子域划分是企业高层管理意图在软件系统架构中的终极体现。

它通过**将问题空间划分为核心域、支撑域与通用域，明确了软件系统不同模块的竞争价值与自主研发红线**；并通过**科学指引研发资源的战术倾斜，避免了边缘业务过度开发与核心业务资源匮乏的双重灾难**。掌握这套战略子域拆分与边界防守技术，是主导数字化转型、带领大型微服务集群架构重构的技术领袖的核心必修功底！