领域划分的规则是什么？

大家好，欢迎来到IT知识分享网。

一、背景

最近有微信朋友在公司内部分享的时候有人问领域划分的规则是什么？意思就是你怎么知道一个领域需要划分哪些子领域？有没有依据，是凭直觉吗？本文将重点讨论下这个比较现实的问题。同时根据网友的试读建议本文进行了思维导图的总结，可以保存收藏。

本文先找人进行了试读，有大佬提出了一些建议，为了让本文更容易让人理解，这里我们不再具体讨论领域模型、子领域、限界上下文和聚合的概念，而是聚焦于对一个宽泛意义上的领域来划分，另外当你真正深入领域划分过程的时候，其实这些词在某些情况下是等同的，比如上下文，领域，子领域这三个词。所以对于划分出来的划分方案可能就是一份文档，一个对于应用架构落地的指导性方案。那么这时候，领域可能是一个部门负责的，可能是一个平台系统，可能是一个单独的微服务，也可能是更细致上的模块。

最终，当你觉得概念很难理解的时候不妨先放一下，去真正体验一下领域驱动设计中的统一语言在现实情况下的应用场景。

二、领域划分的依据

现在我们先直观的回答这个问题，我这边从以下个方面来阐述一下领域划分的依据，可能不够全面，如果有其他依据欢迎交流讨论。

2.0 领域划分依据的思维导图

2.1 基于领域模型的对象关系

2.2 基于数据模型的对象关系

从数据模型上不是特别能看出来领域划分的依据，但是我们可以从中找到一些线索，比如一些表之间跟另外一些表之间本身有些数据的流动关系，或者依赖关系。或者我们通过几个被依赖的表去发现被依赖的表本身就代表着这个表可能就是一个核心表，那么核心表对外而言就只需要通过其ID或者业务标示字段进行关联，内部的表都可以通过这个表的ID来遍历找到。一个特殊的案例就是我们会因为性能等方面的原因来打破数据库范式的约束，比如做冗余，但是这个冗余的字段却很明显的不能当作表间关系的依据。一个超过10张表的e-r图从布局上就可以看出这些表之间的亲缘关系。

2.3 基于业务流程的交互关系

2.4 基于抽象复用的要求

2.5 基于角色和职责的定位

2.6 基于团队协作的方式

三、领域划分的规则或者原则

上面从各个方面来阐述来一些领域划分的依据，那现在我们总结一下相关的规则或者原则，领域划分的规则其实跟聚合或者上下文划分的规则很类似，基本上大同小异，小异的地方等有时间再分享下。因此我也重点看了张逸老师的《解构领域驱动设计》的书，把其中关于上下文和聚合相关的原则拿过来简单说明一下。

3.0 领域划分的规则或者原则思维导图

3.1 单一抽象层次原则

这个原则其实要求做领域划分的时候不可以抽象出多个相似的领域，比如营销和优惠，这两个可能就是相似的领域，或者说优惠是在营销领域下的一个层次的抽象，那这样的话我们可以用这个原则来检查一下划分的领域有没有可能存在相似和重复。当然另外一方面也可以保障我们可以识别大多数的重要领域。

3.2 奥卡姆剃刀原理

这个在书里说的意思是在划分上下文的时候不要做的太细，太细的话就存在多个层次的内容反而无法更好的切分上下文，那么在领域层也类似，说白了，通过这个原理可以让主观的划分更有能动性，也更能给出划分的理由。即使是拍脑袋划分的，能从中取出核心的领域名称并给出具有说服力的理由也算一种划分方案。

3.3 最小惊讶原则

这个原则说的是在真正懂行的专家里或者有经验的大佬面前如果你的划分挺合理的话那么他们不会感到惊讶，可能会会心一笑。反之就会觉得有需要改进的地方，或者再讨论讨论。所以在领域和上下文的划分上来看，如果划分的比较合理那么就没有太多争论的必要了。

3.4 正交原则

这个正交原则其实可能有点不太理解或者不容易应用，在领域划分方案出来之后可以通过一些业务流程来看一下领域内的聚合实体服务等是否跟别的领域内做的事情相似或者一样，如果存在的话说明还可以继续优化。直到每个领域做的事情都足够唯一或者职责单一，到合适的正交维度即可。如果过度的追求正交和职责单一可能会出现3.1的情况。

3.5 多数派原则

四、领域划分的方法

从现在看领域的划分可能比聚合和上下文的划分更有难度，领域本身涉及的维度其实是多维的，所以在正交上只是选择某一维度去划分，说白了就是在边界上其实领域是更模糊的，有时候上下文就可以代表领域，但是领域其实可能不能跟上下文去划等号。所以领域划分的话其实是对时空间的划分，比如生态系统，12306购票系统，这些系统其实是跨空间在时间上并行的。业务流程是源源不断的通过各个领域。所以通过上面的一些依据，规则或者原则能帮我们区分领域的问题空间和解空间，以及将这些业务流程从时间维度上来验证划分的结果是否合理。

五、总结

这个话题其实也让很多学DDD的人又多了一个问号，但是如果这个话题讨论清楚了那么我们对于DDD和领域相关的知识理解又深了一些，本文也仅通过自己的所思所想表达一下这个话题相关的内容，如果有补充的或者哪里不对欢迎讨论。