领域核心战略：解密子域（核心域/支撑域/通用域）划分准则与资源分配规范

在开展大型企业业务系统设计时，许多研发团队往往把所有业务模块混为一谈，平均分配开发精力。这种缺乏战略眼光的做法，往往导致团队在“通用功能”（如用户单点登录）上耗费了 70% 的核心研发力量，而决定企业生死存亡的“核心竞争力”（如量化交易匹配引擎）却因为人手不足而粗制滥造。

为了帮助企业理清业务主次，确保核心研发资源能精准投放到最具商业价值的模块上，领域驱动设计（DDD）提出了**问题空间（Problem Space）**的拆解法宝——**子域划分（Subdomains）**。

本文将系统拆解子域的三大核心分类、划分准则、以及研发资源和技术方案的分配矩阵。

一、 子域的三大核心分类

DDD 根据业务价值和核心竞争力的不同，将大系统拆分为三类性质截然不同的子域：

二、 以电商系统为例的子域划分拓扑

我们以一个大型电商系统为例，其问题空间的子域划分以及研发投入的配比拓扑如下：

      [ 大型电商系统问题空间 (Problem Space) ]
                         │
      ┌──────────────────┼──────────────────┐
      ▼ (核心域: 占70%精力) ▼ (支撑域: 占20%精力) ▼ (通用域: 占10%精力)
 [ 智能推荐/动态定价 ]     [ 订单流转处理 ]       [ 用户认证/短信通道 ]
  - 核心算法，高频迭代      - 流程固定，标准支撑    - 行业标准化，通用底层
  - 战略自研                - 内部常规自研          - 采购外部成熟 SaaS / 软件
      │                          │                      │
      ▼                          ▼                      ▼
  [ 精英自研团队 ]          [ 普通业务开发组 ]      [ 采购 SaaS 接入 API ]

三、 资源分配与技术方案决策矩阵

在进行微服务落地和团队划分时，子域的划分直接决定了架构师对技术方案 and 人力配比的决策：

package com.company.strategy.subdomain;

/**
 * 战略域定义与资源配置规约说明
 */
public enum SubdomainType {
    
    /**
     * 核心域：高薪自研，采用 DDD 战术模式（充血模型）
     */
    CORE {
        public String getRndStrategy() {
            return "指派核心架构师团队，采用 DDD 战术充血模型，100% 深度自研，保证持续重构与高频迭代。";
        }
    },

    /**
     * 支撑域：常规自研，可采用传统三层架构（贫血模型）以提升开发效率
     */
    SUPPORTING {
        public String getRndStrategy() {
            return "采用常规三层架构，快速实现业务流程增删改查（CRUD），支持业务平稳运行即可。";
        }
    },

    /**
     * 通用域：零开发，外部采购或直接调用云服务商 API
     */
    GENERIC {
        public String getRndStrategy() {
            return "采购市面上最成熟的 SaaS 产品或开源组件，通过防腐层（ACL）网关进行轻量化接入，拒绝自研。";
        }
    };

    public abstract String getRndStrategy();
}

四、 总结

子域划分（Subdomain Demarcation）是决定软件项目成败、控制研发成本的核心商业艺术。

它通过**基于商业核心价值的问题空间精细拆解，将企业的有限研发资源从繁杂的通用化逻辑中解放出来，聚焦于提供核心竞争力的业务演进**；并**结合不同的软件架构开发规范（核心域充血 vs. 支撑域贫血），达成了研发成本、开发速度与高表达力模型的最优平衡**。掌握这套战略子域划分与技术方案决策矩阵，是担当企业级技术合伙人、主导中大型复杂商业系统战略规划的看家基本功！