02 | 领域、子域、核心域、通用域和支撑域

本篇要搞懂的 5 个概念：领域、子域、核心域、通用域、支撑域。

DDD 的名词很多——限界上下文、聚合、聚合根、实体、值对象还没登场，光这 5 个先吃透。

学 DDD 的关键不是背名词，而是吃透背后的设计思想：

这些思想在 IT 战略设计、业务建模、微服务拆分中都通用；
名词本身在写代码时不一定全用得到，但理解它在解决什么问题很重要。

所以下面的笔记，重点放在"概念在解决什么问题、什么场景下能用到"，标准定义只做辅助。

如何理解领域和子域？

我们先看一下汉语词典中对领域的解释：“领域是从事一种专门活动或事业的范围、部类或部门。”百度百科对领域的解释：“领域具体指一种特定的范围或区域。”

两个解释有一个共同点——范围。没错！领域就是用来确定范围的，范围即边界，这也是 DDD 在设计中不断强调边界的原因。

在研究和解决业务问题时，DDD 会按照一定的规则将业务领域进行细分，当领域细分到一定的程度后，DDD 会将问题范围限定在特定的边界内，在这个边界内建立领域模型，进而用代码实现该领域模型，解决相应的业务问题。简言之，DDD 的领域就是这个边界内要解决的业务问题域。

既然领域是用来限定业务边界和范围的，那么就会有大小之分，领域越大，业务范围就越大，反之则相反。

领域可以进一步划分为子领域。我们把划分出来的多个子领域称为子域，每个子域对应一个更小的问题域或更小的业务范围。

我们知道，DDD 是一种处理高度复杂领域的设计思想，它试图分离技术实现的复杂度。那么面对错综复杂的业务领域，DDD 是如何使业务从复杂变得简单，更容易让人理解，技术实现更容易呢？

其实很好理解，DDD 的研究方法本质上就是"分而治之"——把复杂问题一步步切小，每一块单独研究、单独实现，最后再拼回完整的业务能力。下面我们直接用一个大家都熟悉的场景来走一遍这个过程——开一家咖啡店。

"经营一家咖啡店"涉及的所有事情，就是一个完整的业务领域。早期的小店老板，会把"做咖啡、收钱、记账、订豆子、排班"全都揉在脑子里和一个小本子里——这就是单体系统的样子，老板自己就是那个 All-in-One。

但当门店扩张到 10 家、100 家时，老板的脑子和小本子就 hold 不住了。这时就需要把业务拆开、分工管理，对应到 IT 系统就是引入分布式微服务架构。而要做微服务化，就必须先划分领域边界、建立领域模型。

第一步：确定研究对象（领域）。
研究对象就是"经营一家咖啡店"这件事的全部。

第二步：把领域切成子域。
按照业务关联度和流程边界，可以切成：

产品域：配方研发、出品标准
门店域：点单、出杯、堂食体验
会员域：注册、积分、储值
供应链域：咖啡豆采购、原料库存、配送
人力域：招聘、排班、培训
营销域：活动、券、社群

第三步：把子域继续切成子子域。
比如"产品域"还能继续拆成：咖啡豆烘焙、配方研发、季节新品研发。

第四步：切到最小单元为止。
在"配方研发"这个最小单元（限界上下文）内，可以建立配方研发的领域模型，最后映射到系统就是"配方管理微服务"。这个最小单元就是我们要落地实现的最小边界。

这里先剧透一点聚合、聚合根、实体以及值对象的概念，我会在 [第 04 讲] 和 [第 05 讲] 中详细讲解。

你可以把"一杯咖啡订单"理解为 DDD 的聚合——它由订单号（聚合根）、咖啡品类、糖度、温度、奶量等一组实体和值对象组成，这些元素一起协作完成"一杯咖啡的制作与履约"这个完整业务动作。这个过程类似 DDD 设计时，确定微服务内功能要素和边界的过程。

总结一下：每一个细分到底的子域都会有一个知识体系，也就是 DDD 的领域模型。所有子域的领域模型拼起来，就是整个咖啡店业务的全域模型。再把每个领域模型映射成系统，就得到了一整套微服务。

那么你可能会说，我也不是开咖啡店的，怎么理解这个过程呢？没关系，不同行业的业务模型可能不一样，但领域建模和微服务建设的过程和方法基本类似。其核心思想就是将问题域逐步分解，降低业务理解和系统实现的复杂度。你完全可以拿你最熟悉的业务（哪怕是学校门口的奶茶店、楼下的便利店）来套这个流程。

如何理解核心域、通用域和支撑域？

在领域不断划分的过程中，领域会细分为不同的子域，子域可以根据自身重要性和功能属性划分为三类子域，它们分别是：核心域、通用域和支撑域。

决定产品和公司核心竞争力的子域是核心域，它是业务成功的主要因素和公司的核心竞争力。没有太多个性化的诉求，同时被多个子域使用的通用功能子域是通用域。还有一种功能子域是必需的，但既不包含决定产品和公司核心竞争力的功能，也不包含通用功能的子域，它就是支撑域。

这三类子域相较之下，核心域是最重要的，我们下面讲目的的时候还会以核心域为例详细介绍。

继续用咖啡店来类比这三类子域：

类型	判断标准	咖啡店例子	企业系统例子
核心域	顾客为什么选你不选别家？你的护城河在哪？	咖啡风味、独家配方、品牌调性	公司最赚钱、最差异化的业务模块
通用域	这功能谁家都要，市面上随便买	收银 POS、扫码点单、会员积分	认证、权限、消息推送、文件存储
支撑域	业务必需，有行业特点，但不决定输赢	咖啡豆库存管理、员工排班	数据字典、内部审批、报表中心

一句话区分：核心域是"我做"，通用域是"买就行"，支撑域是"将就做做也能用"。

那为什么要划分核心域、通用域和支撑域，主要目的是什么呢？

还是拿咖啡店来说。我们把咖啡店切成了产品、门店、会员、供应链、人力、营销等若干子域，那哪个才是核心域呢？

答案是：取决于你想做一家什么样的咖啡店。

如果你想做的是"一杯能让人记住味道的精品咖啡馆"，那么 产品域（豆子烘焙、手冲配方）就是核心域，其他都是配角；
如果你想做的是"覆盖一二线城市的连锁品牌"，那么 供应链域（配送、库存、品控一致性）才是核心域，因为单店再好喝，开不出 100 家也是白搭；
如果你想做的是"靠 App 卖券、靠数据复购的线上咖啡品牌"，那么 会员域 + 营销域才是核心域，产品反而是数字化的载体。

同一个咖啡店领域，不同的战略选择会指向完全不同的核心域。核心域不是天注定的，是由你的商业模式定义出来的。

为了保证核心域的资源投入，你甚至会主动收缩其他子域。比如做精品咖啡馆时，你会用现成的扫码点单 SaaS（通用域外购）、用最简单的排班 Excel（支撑域将就），把人力和钱都砸在豆子和咖啡师培训上。

同样的道理，公司在 IT 系统建设过程中，由于预算和资源有限，对不同类型的子域应有不同的关注度和资源投入策略，记住好钢要用在刀刃上。

很多公司的业务，表面看上去相似，但商业模式和战略方向是存在很大差异的，因此公司的关注点会不一样，在划分核心域、通用域和支撑域时，其结果也会出现非常大的差异。

比如同样都是卖茶饮的几个连锁品牌：

品牌	商业模式	核心域
喜茶	高端潮流、新品迭代	产品创新 + 品牌调性
蜜雪冰城	极致性价比、加盟扩张	供应链效率 + 加盟管理体系
瑞幸	数字化直营连锁	App + 私域运营 + 数据驱动选品
茶颜悦色	区域文化体验	国风设计 + 门店氛围 + 地域文化

四家都是卖饮品的，但护城河长在完全不同的地方：

喜茶在拼"下一款爆品"，所以产品研发是核心域，门店运营、收银这些反而是支撑/通用域；
蜜雪冰城在拼"全国最便宜还能赚钱"，所以供应链和加盟管理是核心域，单店的产品研发反而不那么重要；
瑞幸在拼"用 App 和算法把顾客留住"，所以数字化系统就是核心域，连饮品研发都是为数据闭环服务的；
茶颜悦色在拼"顾客愿意排两小时队的体验"，所以门店设计与文化输出是核心域。

商业模式的不同会导致核心域划分结果的不同。在公司领域细分、建立领域模型和系统建设时，我们就要结合公司战略重点和商业模式，找到自己的核心域，并把最好的资源砸进去。

如果你的公司刚好有意向转型微服务架构的话，我建议你和你的技术团队要将核心域的建设排在首位，最好是有绝对的掌控能力和自主研发能力，如果资源实在有限的话，可以在支撑域或者通用域上想想办法，暂时采用外购的方式也未尝不可。

总结

领域的核心思想就是将问题域逐级细分，来降低业务理解和系统实现的复杂度。通过领域细分，逐步缩小微服务需要解决的问题域，构建合适的领域模型，而领域模型映射成系统就是微服务了。

核心域、支撑域和通用域的主要目标是：通过领域划分，区分不同子域在公司内的不同功能属性和重要性，从而公司可对不同子域采取不同的资源投入和建设策略，其关注度也会不一样。

先把"是什么"回答清楚

概念	官方定义（DDD 标准说法）	一句话大白话	咖啡店里的例子
领域（Domain）	业务问题的边界范围，是 DDD 进行建模和分析的对象，代表一个特定的业务空间	你要解决的全部业务问题的范围	经营一家咖啡店这件事的全部
子域（Subdomain）	对领域进行进一步细分得到的、范围更小、关注点更聚焦的问题域，是构建领域模型的基本单位	把领域切小后的每一块	产品域、门店域、会员域、供应链域、人力域、营销域
核心域（Core Domain）	决定产品和公司核心竞争力的子域，是业务成功的主要因素，需投入最优资源进行自研	决定你赢不赢的子域，护城河所在	想做精品咖啡馆 → 产品域是核心
通用域（Generic Subdomain）	没有太多个性化诉求、同时被多个子域使用的通用功能子域，通常已有成熟解决方案可直接采购	谁家都要、市面上随便买的功能	收银 POS、扫码点单、会员积分
支撑域（Supporting Subdomain）	业务必需的子域，但既不包含核心竞争力，也不属于通用功能，往往具有一定行业特性	业务必需、有行业特点、但不决定输赢的功能	咖啡豆库存管理、员工排班

注意三件事：

领域和子域是"切大小"，回答"业务范围有多大"。
核心 / 通用 / 支撑是"贴标签"，回答"这块业务对我有多重要"。
核心域不是固定的，由你的商业模式决定——同样卖咖啡，精品店、连锁店、线上店的核心域完全不同。

再讲"为什么要这么分"

领域细分的目的：把复杂业务逐级拆小，降低理解和实现的难度。每个最小子域最终映射成一个微服务，所有微服务拼起来就是一整套业务系统。

贴标签的目的：公司预算和人力都有限，必须取舍。把最强的人和最多的钱砸在核心域，通用域直接买 SaaS，支撑域能用就行。划错了类，把资源砸到支撑域上，核心竞争力就建不起来。

一句话速记

领域定范围，子域分而治之；核心 / 通用 / 支撑决定钱该往哪里花。

落地建议

如果你正在做一个新业务或要做微服务化改造，可以按这个顺序走：

画领域全景图：把业务里所有要做的事列出来，这是领域。
切子域：按业务关联度和流程边界切成 5–10 个子域，必要时继续细切。
贴标签：对每个子域问三个问题——
- 它是顾客选我不选别家的理由吗？→ 是 = 核心域
- 别家也都要做、市面上有现成方案吗？→ 是 = 通用域
- 它对业务必需，但不影响输赢吗？→ 是 = 支撑域
分配资源：核心域自研、通用域外购、支撑域将就，把钱花在刀刃上。

思考题

请结合你所在情况，尝试给业务做一个领域拆分，看看哪些子域是核心域，哪些子域是通用域和支撑域？