子域与核心域（Subdomain）
用途：决定哪些模块值得投入建模、哪些应当外购或简化时查阅
定义
「定义」小节链接子域是对问题空间（业务本身）的分解结果：把整个业务领域切分成若干相对独立的部分，每一部分承载一类业务能力。子域属于业务视角，与解空间里的限界上下文（模型视角）不是同一层东西。
三类子域按“是否构成竞争优势”区分：
| 类型 | 特征 | 投入策略 |
|---|---|---|
| 核心域（Core） | 决定业务竞争力，规则复杂且持续演进，做不好直接影响经营结果 | 最强的人、完整建模、允许长期重构 |
| 支撑域（Supporting） | 为核心域服务，有一定业务规则但无差异化价值 | 简化建模，够用即可，可随核心域调整 |
| 通用域（Generic） | 行业通用、市面有成熟方案（身份权限、组织、消息通知、审批引擎、报表） | 外购或复用平台能力，不要自研 |
由来与要解决的问题
「由来与要解决的问题」小节链接资源分配问题。团队习惯把同样的工程标准撒到所有模块上，结果是核心业务拿不到应有的设计投入，边缘功能却消耗了大量重构预算。子域划分的作用是把“哪里值得花钱”变成显式决策。
Evans 在《领域驱动设计》中把它作为战略设计的第一步：先分解问题空间并标注价值，再谈模型与边界。
判定方法
「判定方法」小节链接单靠“这块业务很重要”无法判定核心域，用三个问句：
- 做差了对经营结果的影响是否可感知？（转化率、成本、合规风险、履约时效）
- 规则是否频繁变化，且变化本身来自业务策略？（如果三年不变，多半不是核心）
- 竞争对手是否难以复制这部分能力？（可复制的一律降级为支撑或通用）
三条中两条成立 → 核心域。只满足第 1 条且规则稳定 → 支撑域。三条都不满足 → 通用域。
辅助信号：缺陷集中在哪、需求变更集中在哪、业务专家的时间花在哪。核心域通常也是“业务方愿意来讨论规则细节”的地方。
与限界上下文的关系
「与限界上下文的关系」小节链接| 维度 | 子域 | 限界上下文 |
|---|---|---|
| 空间 | 问题空间（业务是什么） | 解空间（系统怎么组织） |
| 归属 | 业务视角，与实现无关 | 架构视角，由建模决定 |
| 数量关系 | 一个核心子域可对应多个上下文（按团队与一致性需要细分） | 一个上下文通常只服务一个子域 |
映射原则：核心子域要单独成上下文，避免它的模型被支撑域或通用域的概念污染；通用子域尽量以适配方式接入，不进入核心模型。
常见实现形态
「常见实现形态」小节链接- 能力地图标注：在业务能力清单上标核心/支撑/通用，并附投入策略与负责人，作为架构资产维护。
- 差异化构建决策（Buy vs Build）：通用域优先选用成熟组件（工作流引擎、权限中心、搜索服务、消息平台），把自研预算留给核心域。
- 团队与代码结构对齐：核心域配稳定的长期团队；通用域可由平台团队维护，业务方只消费接口。
常见误区
「常见误区」小节链接| 误区 | 后果 |
|---|---|
| 所有模块都按核心域标准建模 | 交付变慢、抽象层泛滥，团队对方法产生抵触 |
| 把“技术复杂”当成核心域 | 高并发、大数据量属于规模复杂度，不是业务差异化，投入方式完全不同 |
| 自研通用域（自己写审批引擎、权限系统） | 长期维护成本吞噬核心域预算 |
| 核心域与支撑域共用一个模型 | 支撑域的变更频繁侵入核心域，规则被绑架 |
| 一年前标注的核心域不再复核 | 业务重心迁移后，投入错配 |
与其他概念的关系
「与其他概念的关系」小节链接- 限界上下文：子域指导上下文划分，上下文承载子域的模型。
- 统一语言：核心域最值得投入术语治理。
- 上下文映射：描述子域/上下文之间的协作与耦合方式。
延伸阅读
「延伸阅读」小节链接- Eric Evans《领域驱动设计》第 4 部分（战略设计）
- Vaughn Vernon《实现领域驱动设计》第 10 章（上下文映射与子域分类）
- Nick Tune 等《Learning Domain-Driven Design》（子域与架构组件映射的现代表述）