【DDD】领域驱动设计中的子域、核心域、通用域、支撑域

引言

​         对于我们认识一件事情来说，如果想要快速的学习，搞懂其内部核心思想，统一语言是一件很重要的事情。比如我们做敏捷开发，我们应该知道敏捷看板是什么东西，scrum master是什么角色，比如我们做C4Model，我们要知道什么叫做系统上下文，什么叫容器 ，知道了这些领域名词能够更好地让我们去学习，去深入理解。

重点词汇

• 领域
• 子域
• 核心域
• 通用域
• 支撑域

        我们看到了，这几个词汇都带有域字，猛地一看，很容易被搞蒙，我们逐一来进行分析,本篇文章就是要和大家一起把这几个词汇搞懂。

领域

        wiki解释： 指某一专业或事物方面范围的涵盖

        所以我们能够知道很重要的一点，领域是有范围的，我们能够根据领域范围的不同来定义界限，定义边界。

        在研究和解决具体业务问题时，DDD会按照⼀定的规则将业务领域进行细分，当领域细分到⼀定的程度后，DDD
会将问题范围限定在特定的边界内，在这个边界内建⽴领域模型，进而用代码实现该领域模型，解决相应的
业务问题。简言之，DDD的领域就是这个边界内要解决的业务问题域。
        既然领域是用来限定业务边界和范围的，那么就会有大小之分，领域越大，业务范围就越大，反之则相反。

子域

        我们举个例子，比如我们要研究的领域是轿车，首先我们先确定了，领域为轿车，如下图所示

        对于研究的领域来说，可能我们需要把一个大的整体区分拆开来理解它，从整体到部分的过程，也是我们在深度学习的过程，比如我们拆分 发动机、离合器、变速箱、车轮、气囊、内饰，这些是轿车的子域，一个领域是由一个或者多个子域构成的，有些子域还可以再进行拆分，也就是子子域，含义为子域的子域。

        具体再向下拆的过程中我们能够根据功能不同，进行细分，比如发动曲柄栏杆机构和配气机构等，这些组成了发动机，如果我们把发动机理解为领域对象的话，这些发动曲柄栏杆机构和配气机构等可以理解为领域内的聚合、实体、值对象等，要根据不同的业务场景进行对应的判断。

        其实如果我们继续拆分配气机构，其实还可以拆分成 气门组、气门传动组，一直可以拆分到 进气门、排气门、气门导管、气门座及气门弹簧等零件，直到不能拆分，那么这些零件就对应着聚合根、实体、值对象。

        我们发现，我两次描述的，找到的聚合根、实体、值对象是不一样的，所以确定好上下文，确定好业务场景是重中之中，不能说明哪个是对的哪个是错的，只能说明在这个场景下，拆分到这个力度是最合适的。

        当然，具体介绍聚合根、实体、值对象是下一篇文章做得事情，先剧透一下。

为什么要给子域打标

        其实对于我们来说，子域，子子域，子子子域，可以一直拆到不能拆为止，这些拆分出来的结构，对于整体来说都是子域，但是，作为一家公司，业务一定有轻重缓急，认识到哪些业务线重要，哪些业务线比较清缓，有的时候能决定公司的整体效率甚至生死存亡。所以做业务一定要有的放矢。

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

核心域

        核心域，指的是这个业务的核心功能，核心模块。比如，轿车主打的是动力充沛的话，那么发动机一定是核心域，比如说主打的是操控的话，那么变速箱、离合器一定是核心域。

        所以同一产品，在不同的商业角度中，核心重点，核心玩法是不一样的，比如对于电商来说，阿里和京东都是头部企业，那么阿里主要做的是联营模式，这种场景下，返利、租户等系统一定是核心，京东做的是自营模式，那么仓储、wms、供应链一定是核心域。

通用域

        对于汽车来说我们可以把内饰理解为通用域，因为比如说坐垫，比如说化妆镜，这些东西不一定是只能给某一辆单独型号的车来使用的，所以具有一些通用的属性。没有太多客制化的开发工作。

        对于系统来说的话，通用域则是你需要用到的通用系统，比如认证、权限等等，这类应用很容易买到，没有企业特点限制，不需要做太多的定制化。

支撑域

        以汽车为例，我们可以把车轮和气囊作为支撑域来看待，因为对于车轮和气囊来说，它们的大小尺寸是严格和车辆保持一致的，也就是说不具备通用性，是极具有车厂风采的个性化产品

        对于DDD来说，支撑域则具有企业特性，但不具有通用性，例如数据代码类的数据字典等系统。

下一篇文章讲下聚合根、实体和值对象