一、领域、子域、限界上下文

一、简介

领域驱动设计，Domain-Driver-Design，简称为DDD。

DDD是一种思想，用以软件系统的分析和设计。由领域来驱动设计的进行，这里的领域可以简单理解为我们常说的“业务”。也即是，由对业务的分析工作来驱动软件设计工作。

听起来好像所有软件都是这样，从业务分析到软件设计，但是一般软件过程中，业务和软件之间存在着一条鸿沟，分析完了，似乎没办法马上转换成软件设计。DDD思想则为了打破这道鸿沟。

DDD自上而下分为战略设计和战术设计，我们可以这么想，战略设计就是从上层进行抽象性设计，而战术设计就是基于上层抽象做下层的具体实现设计。

本文涉及的领域、子域、限界上下文就是属于战略设计。也就比较抽象，在DDD书籍当中看起来也显得有些晦涩。

不过对于思想层面的东西，我们不应该要求自己一下子就完全跟作者契合。而是通过自己的理解和不断实践，一步步让思想不断加深。所以，不要太纠结于自己是不是理解的不正确。

二、概念

什么是领域？

我们可以把领域当作一个大的问题域来理解，如果对一个企业来说，那么就是这个企业要做的所有事情。

什么是子域？

子域是相对于领域的一个概念，顾名思义就是领域被细化以后分成了不同的子域。这个应该相对比较好理解，因为我们人习惯性的会将大的东西进行分割，然后逐个击破。比如“分层思想”，“模块化思想”等。

那么子域就是将一个大的问题域拆分成了很多小的问题域。

并且根据子域的重要性以及作用范围将子域分成了：

1、核心域：重要性最强

2、支撑子域：重要性较低，辅助核心域

3、通用子域：给所有域提供辅助

什么是限界上下文？

开发软件的目的就是为了解决问题，领域定义了问题域，子域细分了问题域。那么我们需要考虑如何根据这些问题域来设计解决方案。

我们说的解决方案就是“领域模型”，领域驱动设计即根据问题域来进行建模。

可是我们想一下，如果我们对整个领域建立一个模型是不是太可怕了，如果系统过于庞大，那么这个模型也将非常庞大，牵一发动全身。

既然模型不好建得太庞大，那么我们可以根据细分的子域来建模型。

比较理想的情况是我们根据一个子域单独建立一个模型，也就是一个问题有一个解决方案。这是比较理想化，有时候我们会遇到一个模型能会对应多个子域，或者多个模型对应一个子域的情况。就是说我们可能需要多个解决方案一起来合作把一个问题解决，或者一个解决方案能够解决多个问题。

那，限界上下文在子域和模型这里起到什么作用呢？

我们姑且认为，限界上下文就是将模型对应的子域给框定一个范围，就是说我这个方案要解决的问题包括这些内容。从这个角度，我们可以将领域模型和限界上下文理解为一对一的关系，而通常一个限界上下文将成为一个系统。因此，我们简单地去认为（实际中这个等式并不准确）：领域模型 = 限界上下文 = 一个系统 

事实上，限界上下文包含的不只是一个领域模型，还有通用语言，领域服务...等不少东西，这里不去讨论这些内容。

三、总结

本文不求甚解，将领域和子域映射为问题域的确定和细分，将领域模型作为问题域的解决方案，将限界上下文认为是为领域模型框定了一个范围表示领域模型解决了那些问题。

在进行战略设计的过程中，主要在于如何确定问题，以及确定要构建哪些模型来解决什么问题。

你根据问题域去设计解决方案的过程也即是领域如何驱动设计的过程。