DDD系列-领域划分

什么是领域划分

领域划分是以分离关注点为原则对问题空间的划分。领域划分必然会划分成很多个子域。

子域是领域中某个方面的问题和解决它所涉及的一切。

其实我们面对复杂问题的时候，都会采用这种方式，纵观我们整个社会，有各行各业，有餐饮业，保险业，房地产业，然后每个领域解决自己领域内的问题，最后连接成一个高效运作的社会形态。

同样，我们做互联网如果要达到高效运作的效果，就必须做到各司其职，做细做精。但是这里有一个难题，如果做领域划分，就跟社会上不会平白无故出现一个保险业一样，它肯定有社会普遍的问题，最终人们抽象成了一个保险业领域来解决保险相关的所有问题。

假设没有领域划分

其实很多业务初期的时候，都是没有领域划分的，基本是按照需求来。接下来我们看下，如果这样长期演变下去会有什么问题。笔者是做医疗的，还是用那个医疗的用户故事来讲解。

我们假设梳理出来了下面几个顶层用户故事

1）收集用户的病情

2）用户购买订单

3）指派订单给医生

4）医生接单

5）医生和患者IM对话

6）医生开具处方

7）用户购买处方药

假设在一个项目压力比较大，而研发leader又没有做太多思考的情况下，很容易将这6个顶层用户故事派发给6个研发同学，也就是按照需求来划分指责。

这样会导致：

1）问题点和领域知识重叠，比如"用户提交订单"和"用户购买处方药"都会处理支付问题，支付领域的问题他们都需要处理一遍，痛苦加倍

2）基础模型重叠，比如"收集用户病情"和"医生接单"和"用户购买处方药"都会用到就诊人和病例的模型，他们很可能自己定义一套内部的模型，将来想打通简直就是噩梦

3）难以区分核心和非核心，如果你作为一个在线医疗系统，结果一半的人力在支付问题上，那可想而知，医疗真正的核心问题谁来解决？

领域划分解决的问题

很多人可能已经想到了，建立通用底层服务，然后上层业务统一调用底层服务，这样可能有一定的思路了，但是还不够彻底，因为一旦涉及到服务，就会涉及到拆分的依据和原则，这个问题就相当复杂了。所以我们假设带着这个思路去拆分一下上面的用户故事划分的域。

1）交易域，首先能想到的是交易域，这里处理支付相关的问题，所以支付领域的问题汇聚到这

2）订单域，这里包括订单，商品等重要的信息

2）对话域，作为医生和用户的医疗IM通用工具，这里需要处理各种个性化的通信协议，比如医嘱，病例等医疗特性内容

3）医生域，医生具备接单，看病，开处方等能力

所以还是上面的用户故事，但是人员的分配却千差万别

现在看看，如果我们充分做了领域划分（这里只是列举一个例子，可能医疗系统真实的领域划分不同），那可以解决我们按照需求来分配人员的缺点

1）问题点和领域知识聚焦，做支付那一波人每天都和支付问题打交道，做对话域那一波人每天都在和IM系统打交道

2）基础模型被拆分，订单和商品模型只在交易域里面

3）可以区分核心非核心，这里面医生域和交易域是核心，必须重点投入人力，前期我们可以投入更少的人力做功能有限的支付域和对话域

实际上，在DDD的思想中，根据重要性与功能将领域分为大致三类（视项目实际情况而定）的多个子域，分别是核心子域、支撑子域和通用子域。核心域是业务成功的主要促成因素，主要竞争力，支撑子域是支撑核心域的，而通用子域是业务系统的公用部分。

如何合理的进行领域划分

既然领域划分之后，人员可以高效的协作，但是，如果领域划分不合理，会导致开发人员的领域知识各种交叉，不排除逐步走向单体的可能，带来的灾难一样巨大的。所以合理的领域划分相当重要。这里有几种方法

1）参考行业，市面上比较成熟的领域，比如电商，金融，财务

最快的方式是招一个领域架构师直接划分，架构师的能力相当强，直接通过直觉和经验进行划分

2）基于用户故事方法，既然用户故事是对问题的描述，领域划分是对问题的分界，所以可以从这个角度出发

可以从整个产品涉及的角色，以及每个角色的用户故事描述出来，比如很容易区分运营域，用户域，他们做的事情完全不一样

下面介绍一种常用的模式，纵+横划分

基于用户故事的纵+横划分

因为领域的划分属于问题空间，所以当我们讨论领域划分的时候，只聚焦于问题。避免有任何技术相关的术语插入（比如模型，限界上下文）

首先需要把问题全部摆出来，然后有两个原则：

1）纵：根据业务目标和价值垂直划分

2）横：共性能力提取，划分通用域和支撑域

用户故事是非常复杂的，但是一定要列全，否则不可能再做横向划分，如果这一步划分的好，那产品架构和技术架构是比较接近的。

（注意：一下概念全部来自用户故事，因为在盘点的时候，每个业务都用到了这些概念，才会考虑下沉）

这里使用医疗领域典型的"医+药"模式来构建一个典型的领域划分，用户故事来自知乎的阿里健康的（实际的情况比这个更复杂）

https://zhuanlan.zhihu.com/p/125144917

值得一提的是，这个图不是什么微服务架构图，这里没有任何技术的概念，仅仅是从用户故事出发得出来的领域划分。

下一个环节

我们上面的讨论都是在问题空间进行的，注意还没有到具体的解决方案空间，这时候才开始出现一些界限上下文的词语