 下载APP 

02 | 领域、子域、核心域、通用域和支撑域：傻傻分不清？
2019-10-16 欧创新
DDD实战课 进入课程 

你好，我是欧创新。

讲述：欧创新
时长 13:04 大小 10.48M


DDD 的知识体系提出了很多的名词，像：领域、子域、核心域、通用域、支撑域、限界上下文、聚合、聚合根、实体、值对象等等，非常多。这些名词，都是关键概念，但它们实在有些晦涩难懂，可能导致你还没开始实践 DDD 就打起了退堂鼓。因此，在基础篇中，我希望能带着你一起做好实践前的准备工作。

除此之外，我想说的是，这些名词在你的微服务设计和开发过程中不一定都用得上，但它可以帮你理解 DDD 的核心设计思想和理念。而这些思想和理念，在 IT 战略设计、业务建模和微服务设计中都是可以借鉴的。

那么，从这讲开始，我就会围绕以上这些 DDD 关键概念进行讲解，帮助你彻底理清它们与微服务的关系，了解它们在微服务设计中的作用。今天我们重点了解 DDD 的领域、子域、核心域、通用域和支撑域等重要概念。

如何理解领域和子域？

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

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

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

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

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

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

其实很好理解，DDD 的研究方法与自然科学的研究方法类似。当人们在自然科学研究中遇到复杂问题时，通常的做法就是将问题一步一步地细分，再针对细分出来的问题域，逐个深入研究，探索和建立所有子域的知识体系。当所有问题子域完成研究时，我们就建立了全部领域的完整知识体系了。

我们来看一下上面这张图。这个例子是在讲如何给桃树建立一个完整的生物学知识体系。初中生物课其实早就告诉我们研究方法了。它的研究过程是这样的。

第一步：确定研究对象，即研究领域，这里是一棵桃树。

第二步：对研究对象进行细分，将桃树细分为器官，器官又分为营养器官和生殖器官两种。其中营养器官包括根、茎和叶，生殖器官包括花、果实和种子。桃树的知识体系是我们已经确定要研究的问题域，对应 DDD 的领域。根、茎、叶、花、果实和种子等器官则是细分后的问题子域。这个过程就是 DDD 将领域细分为多个子域的过程。

第三步：对器官进行细分，将器官细分为组织。比如，叶子器官可细分为保护组织、营养组织和输导组织等。这个过程就是 DDD 将子域进一步细分为多个子域的过程。

第四步：对组织进行细分，将组织细分为细胞，细胞成为我们研究的最小单元。细胞之间的细胞壁确定了单元的边界，也确定了研究的最小边界。

这里先剧透一点聚合、聚合根、实体以及值对象的内容，我还会在 [第 04 讲] 和 [第 05 讲] 中详细讲解。
我们知道细胞核、线粒体、细胞膜等物质共同构成细胞，这些物质一起协作让细胞具有这类细胞特定的生物功能。在这里你可以把细胞理解为 DDD 的聚合，细胞内的这些物质就可以理解为聚合里面的聚合根、实体以及值对象等，在聚合内这些实体一起协作完成特定的业务功能。这个过程类似 DDD 设计时，确定微服务内功能要素和边界的过程。

这里总结一下，就是说每一个细分的领域都会有一个知识体系，也就是 DDD 的领域模型。在所有子域的研究完成后，我们就建立了全域的知识体系了，也就建立了全域的领域模型。

上面我们用自然科学研究的方法，说明了领域可以通过细分为子域的方法，来降低研究的复杂度。现在我们把这个话题再切换到业务领域，对比验证下，二者的细分过程是否是一致 的。这里以我从事的保险行业为例。

保险是个比较大的领域，很早以前的保险核心系统把所有的功能都放在一个系统里来实现， 这个系统就是我们常说的单体系统。后来单体系统开始无法适应保险业务的发展，因此保险公司开始了中台转型，引入分布式微服务架构来替换原来的单体系统。而分布式微服务架构就需要划分业务领域边界，建立领域模型，并实现微服务落地了。

为实现保险领域建模和微服务建设，我们可以根据业务关联度以及流程边界将保险领域细分为：承保、收付、再保以及理赔等子域，而承保子域还可以继续细分为投保、保全（寿
险）、批改（财险）等子子域。

在投保这个限界上下文内可以建立投保的领域模型，投保的领域模型最后映射到系统就是投保微服务。这就是一个保险领域的细分和微服务的建设过程。

那么你可能会说，我不是保险行业的人，我怎么理解这个过程呢？我认为，不同行业的业务模型可能会不一样，但领域建模和微服务建设的过程和方法基本类似，其核心思想就是将问题域逐步分解，降低业务理解和系统实现的复杂度。

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

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

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

这三类子域相较之下，核心域是最重要的，我们下面讲目的的时候还会以核心域为例详细介绍。通用域和支撑域如果对应到企业系统，举例来说的话，通用域则是你需要用到的通用系统，比如认证、权限等等，这类应用很容易买到，没有企业特点限制，不需要做太多的定制化。而支撑域则具有企业特性，但不具有通用性，例如数据代码类的数据字典等系统。

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

还是拿上图的桃树来说吧。我们将桃树细分为了根、茎、叶、花、果实和种子等六个子域， 那桃树是否有核心域？有的话，到底哪个是核心域呢？

不同的人对桃树的理解是不同的。如果这棵桃树生长在公园里，在园丁的眼里，他喜欢的 是“人面桃花相映红”的阳春三月，这时花就是桃树的核心域。但如果这棵桃树生长在果园里，对果农来说，他则是希望在丰收的季节收获硕果累累的桃子，这时果实就是桃树的核心域。

在不同的场景下，不同的人对桃树核心域的理解是不同的，因此对桃树的处理方式也会不一样。园丁更关注桃树花期的营养，而果农则更关注桃树落果期的营养，有时为了保证果实的营养供给，还会裁剪掉疯长的茎和叶（通用域或支撑域）。

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

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

比如同样都是电商平台的淘宝、天猫、京东和苏宁易购，他们的商业模式是不同的。淘宝是
C2C 网站，个人卖家对个人买家，而天猫、京东和苏宁易购则是 B2C 网站，是公司卖家对个人买家。即便是苏宁易购与京东都是 B2C 的模式，他们的商业模式也是不一样的，苏宁易购是典型的传统线下卖场转型成为电商，京东则是直营加部分平台模式。

商业模式的不同会导致核心域划分结果的不同。有的公司核心域可能在客户服务，有的可能在产品质量，有的可能在物流。在公司领域细分、建立领域模型和系统建设时，我们就要结
合公司战略重点和商业模式，找到核心域了，且重点关注核心域。

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

总结

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

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

思考题

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

欢迎留言和我分享你的思考和疑惑，你也可以把今天所学分享给身边的朋友，邀请他加入探讨，共同进步。

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。

上一篇 01 | 领域驱动设计：微服务设计为什么要选择DDD？
下一篇 03 | 限界上下文：定义领域边界的利器

精选留言 **(33)

 写留言
vivi**
2019-10-16
通用域和支撑域对应到企业系统是哪些呢？
展开

作者回复: 通用域是一些大家都需要用的通用系统，比如认证，权限等等，这类应用很容易买到， 不需要做太多的定制化，没有企业特点。支撑域具有企业特性，但不具有通用性，比如数据代码类的数据字典等系统。

1 10





段拙言
2019-10-16
这里没看限界上下文的概念，在桃树的例子中，细胞即为限界的上下文吗？还是说，器官，组织，细胞都是限界的上下文？
展开

作者回复: 你好，段拙言。还是你细心，不过不要纠结这里的限界上下文的概念，限界上下文是由它的语义边界来确定的。在DDD里面一个聚合可以是一个限界上下文，多个不同职能的聚合也可以组成为一个限界上下文，他们都在一个语义环境下。有的组织可能只有单一细胞，有的组织可能由多个不同功能的细胞组成的。我们重温一下生物课哈。由一种细胞所构成的均一组织。而由两种以上细胞构成的不均一的组织称为复合组织。特定功能（特定的语义环境）的组织基本上就可以对应到限界上下文。

2 2





Geek_a91670
2019-10-18
有些领域边界特别模糊,不好划分,例如:某些子领域两边都靠,不知道怎么取舍

作者回复: 看领域大小，不大的话可以考虑放在一个限界上下文内，做成一个微服务。比较大的话，可先做好聚合的边界，以后随时可以根据需要来拆分微服务。

1





Catwell
2019-10-16
13年以前基本是三层架构开发，13年后开始使用DDD，没系统的研究过，只是看了一些资料，我的理解是基于业务的属性，把原先的三层变成N个三层，相互间用接口或者API传 输，不知道我这样理解对不对。

作者回复: DDD包括战略和战术设计两个部分，战略设计完成领域建模，战术设计完成微服务设计。您说的应该属于战术设计的部分，DDD分层架构包括用户接入层、应用层、领域层和基础层四层，每层有不同的服务，职责不同。后面章节有详细介绍，请耐心等待。

1





TH
2019-10-16
终于理解了DDD是可以逐级细化的，大的DDD里应该是可以套小的DDD，也理解了核心域的意义。对于如何确定边界还存在疑问，希望在后面的课程中得到解答。
关于楼上朋友“子子域模型”的说法，其实只要定下一个大家都能理解的术语就行了，这跟DDD提倡的通用语言是一个道理。另外既然问题域可以逐级细化，那么在高层次看是…
展开

作者回复: 非常正确。

 1

huayu00


2019-10-16
“”我们可以根据业务关联度以及流程边界将保险领域细分为：承保、收付、再保以及理赔等子域” —- 根据业务关联度以及流程边界细分的方法能介绍下吗？
展开

作者回复: 你好，huayu00。这一块的设计你可以参考传统的模块的设计方式。模块本身就是某类业务的功能聚合，具有一定的业务功能的内聚性。而对于很多业务场景来说，很多领域的边界就是流程的边界，比如商品、订单、货物，他们分别属于不同的流程，很自然的就形成了业务领域的边界。子域的划分需要结合公司自己的业务的情况，参考领域专家的意见来划分。

 1

密码123456


2019-10-16
对于领域问题来说，可以理解为。对一个问题不断的划分，直到划分为，我们熟悉的，能够快速处理的小问题。然后在对小问题处理在排列一个优先级。
展开

作者回复: 赞一个，理解的非常到位。划分到最小就是聚合，聚合之上就是限界上下文，根据限界上下文建立领域模型，然后设计微服务。

 1

兆哲


2019-10-21
老师，对事件风暴的理解 我去网上查询了一些资料； 事件风暴是不是类似是用户故事呢？

作者回复: 差不多，但是不是一个人做用户故事分析。事件风暴参与的人很多，有项目团队和领域专家，这些人在一起采用头脑风暴的方式进行用户故事分析，找出领域对象，建立领域模型。后
面会有专门的章节来讲解，请耐心等待。



白开水有三种味道


2019-10-21
一个聚合是不是就是一个业务流程中剥离出来的“业务环节”

作者回复: 有一部分情况跟你说的业务环节类似。你可以这样打比方，若干个不同职责的人一起完成一件完整的事情，这些不同的人就是不同的实体或者值对象，完整的事情就是你业务环节里某一个完整业务逻辑。在聚合内将这些实体或值对象组织在一起完成共同的业务目标，这就是聚
合。



守候、


2019-10-19
欧老师，我的理解是：DDD其实是一种方法论，指导我们对特定问题（问题域）进行拆分，划分边界，得到当前场景最好最小最合适的粒度（聚合）。至于其他的其他域定义如核心域、通用域、支撑域等则是自然而然的概念。后续期待老师讲解这个拆分过程！
展开

作者回复: 对的，这三种域的设计过程和方法都是一样的。



Benjamn


2019-10-18
欧老师，擅长用类比的方式讲解DDD的许多概念和关系。让人非常容易理解，表示十分感谢！非常期待，关于聚合伦理聚合体，实体和值对象的讲解。
展开

作者回复: 谢谢。能让大家理解这些抽象的概念感到很高兴。敬请期待。



Geek_2973a9


2019-10-17
请问老师，微服务架构物理上是否必须用分布式架构来实施？我理解采用微服务架构是系统具备了以微服务为单位独立部署的能力，但完全还是可以在同一台物理设备上部署。理解对么？

作者回复: 微服务本身就是一种分布式架构的实现方式。微服务要发挥它的价值，最好能够在云平台上来做，利用容器以及DevOps等技术。实际上微服务也是可以跟集中式架构系统一样，部署在物理机上的，但这样失去了它的价值。系统拆的过细，集成成本高，还增加了你的运维压力。





歌在云端
2019-10-17
领域作为一个微服务，那子域是不是就是对外提供的一个个接口

作者回复: 领域到子域是一个细分的过程。这个还到不了微服务。将领域细分到一定程度后，业务就会更加的简单。你就可以采用事件风暴建立领域模型了，领域模型建立后，才能设计微服务。微服务可以对外暴露出一个个的服务。





渊虹
2019-10-17
请教一下老师，我对领域和子域的概念存在一些疑问。课程好像说过，领域对应微服务。核心子领域，通用子领域，支撑子领域也是对应着微服务吗？还是可以理解成，和微服务划分的大小有关

作者回复: 你好，渊虹。子域只是细分领域的过程产物。领域可以细分为子域，子域可以继续划分子子域。这些子域根据重要性和属性特点可以分为核心子域、通用子域和支撑子域。划到一定的子域后，我们就可以开始事件风暴，建立聚合，划分限界上下文，限界上下文可以作为微服务设计和拆分的依据。下一节会讲到，请耐心等待。





zscome
2019-10-17
相同问题域：如何评估各个域划分？微服务粒度如何评估？

作者回复: 你好，你说的各个域是指核心域、通用域和支撑域吗？这个需要结合企业内部的战略来定，属于战略设计。微服务的粒度需要结合企业运维的能力，如果没有CICD和自动化的运维能
力，不建议拆的过细。微服务设计原则里会有详细介绍。请耐心等待。



Jxin


2019-10-16
请教老师 1.问题域的定义？
2.问题域和领域的关系？
3.如何识别出问题域？
4.服务限界如何区分？…
展开

作者回复: 问题域就是你要解决的业务范围，这个范围就是领域。限界上下文根据你的通用语言的业务语义边界来划分。下一节会讲到。



Marshall


2019-10-16
可不可以理解为通用域就是ddd分层中的基础设施层
展开

作者回复: 基础设施层主要是系统运行需要的基础资源，比如数据库服务、总线、api网关等等。通用域是你业务的通用功能，比如用户权限系统。



Geek_e08323


2019-10-16
领域是特定的一个业务范围，由于这个范围比较大而且复杂，需要划分多个子域，使复杂问题变成几个简单问题，从而可以一个个处理，如果其中的子域还是很大，还可以继续划分更小的子域。子域根据职能和重要性分为核心域，通用域，支撑域。其中核心域最为重要，代表公司的核心竞争力，通用域和支撑域可以用花钱买，但是核心竞争力不能买。那么最小的子域可以对应到一个微服务，可以这么理解吗？
展开

作者回复: 小的子领域如果对应到限界上下文，就可以将它拆分微服务了。不过还要考虑其它外部因素，下节讲到，耐心等待。





江河顺水
2019-10-16
领域是个范围的概念。例如针对视频的发行和购买来说，视频的流通就是领域。接下来 流通可以分为视频发行和视频获取两个子域。
发行 又可以继续细分为 审核 存储 渠道 等子子域。获取又可以分为 购买 订阅 等字字域。
…
展开

作者回复: 理解上没有问题。限界上下文要结合业务语义边界，用白话说就是这个阶段就说这个阶段的事，来限定领域模型的业务边界。



atom992


2019-10-16
DDD是研究和解决业务问题的工具和方法，那么什么是DDD做不了的事情呢？DDD能解决的问题和不能解决的问题都是什么呢？这个事情不想清楚，就总会拿DDD试图解决业务问题的方方面面。

作者回复: DDD说白了最终目的还是为了系统建设。企业的复杂业务如果不做细分的话，系统实现的难度和复杂度就会很高，其本质就是通过将复杂问题简单化，分而治之，降低复杂度。



