细心的您可能已经发现了一个规律，DDD使用了一种由上至下的方式来指导系统的构建。第一层考虑如何把大的领域划成多个小的子域，重要性不一样，投入的人和钱肯定也不一样；第二层考虑系统的架构方面，仍然是一类宏观的工作，不过其更加聚焦于如何把大的系统分成几个物理子系统及子系统间的交互方式（如果非微服务架构，就是要考虑分几个包或名称空间）；第三层考虑划小后的子系统自身的架构模式（事件驱动、三层架构、ODD架构、事件源架构等）、领域模型（设计模型）等技术细节。这种从上到下的方式约束着我们在看待问题时应当由宏观到微观，更具条理性。好比您认识一个人，先有一个整体印象然后才能了解对方的三观等问题。
我们上一章对子域做了一个大概的说明，总结起来有四点：1）子域是一种对整体领域的概念上的划分，是人为的主观行为；2）子域的目的是把大的领域划小，使用分而治之的方法来简化系统建设时的复杂度；3）子域的划分不是一成不变的；4）领域有界限，不是无限的大。您常听客户说“我们有这样几块业务”，一般来说这里所谓的”几块儿“就是指子域。谈论子域的时候一般不会涉及过多的技术。假如时间可以倒退50年，那个时候没有电脑，人们用纸记录工人的工资。工资管理通过人工的方式来完成，如何管理就是业务规则，是客观的，和是否有电脑关系不大。
1、子域分类DDD的定义里，子域包含“核心域”、“支撑域”和“通用域”三类，您经常会迷惑为什么会这么定义？怎么理解不同域的作用？如果我分错了是不是对系统影响非常大搞不好会失败？回答您的问题之前我们先看下图对“子域”是如何定义的。
核心域是指业务中最重要的那部分，是您做这个系统的主要目的。核心域体现了企业的个性，比如“的的”中的“打车”功能，这个业务不存在那“的的”可以说是0价值的。所以核心域相对来说很好确定。如果您是甲方爸爸，不建议使用乙方的人做核心域的研发工作除非乙方是“微软”、“IBM”这种牛掰公司。
支撑域主要目的是为了支撑核心业务的运转，关注于业务的某一个方面。以一般的电商购物系统为例，“客户中心”用于支撑商品买卖过程，客户是其中的主体对象；“消息中心”中于支撑交易过程中的如邮件、短信、消息等功能，这两类中心既没有“订购中心”这种核心域业务那么重要，也不能随便找一个开源的来用，里面仍然有许多充满个性化的东西。这一块可内部人员开发也可以考虑外包来做，必须要做好质量与进度管控。
通用域的概念相对而言就比较模糊了：有说“如果子域被用于整个业务系统，这个子域就是通用域。比如保险业务，其核心是‘投保’、‘生成保单’等，电商化后为了让用户在各类渠道如APP、网站、微信小程序等进行各类保险（车险、养老、财产等）的受理而引入了‘订单中心’，这里的‘订单中心’就是通用域，因为他通用于各类渠道和各类保险销售场景”，有点支撑域的味道；有说“通用域用于起到增强的作用，比如我们看视频网站时通常会有的‘收藏’功能”；本文对于这个概念的解释是：通用域的东西一般是有现成的解决方案，可直接购买或下载开源。以此作为解释也是为了对应我们所强调的子域对于资源投入的指导性。
“核心域”是最关键的，“支撑域”和“通用域”相对来说就差了一级，此处的差一级是指资源的投入。
将一个大的领域划分成多个小的子域有两个作用：第一是避免系统混乱，使用分而治之的方式让您或您的团队的关注力更加集中。很多时候，系统的需求在一直无限的扩大而您的团队人数是固定的，先建设哪个后建设哪个得有个先来后到。把业务上分成一块块的，排个优先级，系统开始投入建设后可以让客户在最短的时间内看到成果。您做项目为了赚钱，客户可从中受益；如果客户是甲方时，局方的负责人看到了东西也好对其上级有个交待，大家相互理解好办事儿。第二也是最为核心的，不同的业务域可以让您决定投入的人与钱的数量。比如核心域应该投入最多的钱，能力***的员工；支撑域相对少一点；通用域不行就花钱买一个现成的或直接搞开源。