域

领域

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

子域

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

核心域

决定产品和公司核心竞争力的子域是核心域，它是业务成功的主要因素和公司的核心竞争力

通用域

没有太多个性化的诉求，同时被多个子域使用的通用功能子域是通用域。

支撑域

既不包含决定产品和公司核心竞争力的功能，也不包含通用功能的子域，它就是支撑域。

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

公司在 IT 系统建设过程中，由于预算和资源有限，对不同类型的子域应有不同的关注度和资源投入策略，记住好钢要用在刀刃上。很多公司的业务，表面看上去相似，但商业模式和战略方向是存在很大差异的，因此公司的关注点会不一样，在划分核心域、通用域和支撑域时，其结果也会出现非常大的差异。
商业模式的不同会导致核心域划分结果的不同。有的公司核心域可能在客户服务，有的可能在产品质量，有的可能在物流。在公司领域细分、建立领域模型和系统建设时，我们就要结合公司战略重点和商业模式，找到核心域了，且重点关注核心域。

子域与限界上下文的关系？

在DDD中包括问题域和解决方案域两个不同的维度。问题域主要从业务视角来考虑，完成从领域到子域的分解，而解决方案域则主要从技术实现的角度，通过划分限界上下文和采用DDD战术设计完成微服务拆分和落地。“子域”和“限界上下文”这两个概念分别从不同的视角，构建起了DDD 处理业务复杂度的根基。
个人认为“子域”和“限界上下文”在大多数情况下是一对一或者一对多的映射关系。从实践角度，我们可以这样理解，我们不妨将业务领域的分解拆分为两个阶段：从领域到子域的粗粒度的分解和从子域到限界上下文的技术实现级的分解。有时候企业的业务领域非常庞大，不太方便用事件风暴对整个领域构建领域模型。所以在领域建模之前，我们先根据业务流程边界或者功能集合等要素，将庞大的领域分解成若干个大小合适的子域，然后根据子域属性划分为核心子域、通用子域和支撑子域。当领域分解到足够小后，我们就可以在这些子域内开展事件风暴，划分限界上下文完成领域建模。
在对不同属性子域构建领域模型时，我们可能会有不同的关注点，比如在通用子域构建领域模型时，我们会更多的关注领域模型的抽象和标准化，以便实现企业级复用，这种设计方法与中台的业务建模方法是一致的。当然，如果你的领域足够小的话，我们就没必要进行从领域到子域的分解和属性归类了，你可以直接开展事件风暴，直接划分限界上下文，完成领域建模。按照这种分解方式，如果子域和限界上下文边界刚好一致，那它们就是一对一的关系，而如果在一个子域内还可以划分为多个限界上下文，那我们最终得到的就是一对多的映射关系。需要注意的是，有些通用子域构建出来的领域模型往往会因为复用的需要，可能会跨多个不同的其他业务子域。
限界上下文本质上就是子域，只不过它会更多的考虑领域对象的语义边界和技术实现细节。限界上下文的划分体现的是一种更为详细的设计过程，这个过程划分了业务的上下文语义边界，完成了领域模型，明确了领域对象以及领域对象之间的依赖关系等。我们依据限界上下文和领域模型就可以完成微服务设计和落地了。