关于领域驱动设计，大家都理解错了

翻遍整个互联网，我发现，关于领域驱动设计，大家都 理解错了 。

今天，我们尝试通过一篇文章的篇幅，给大家展示一个完全不同的视角，把「领域驱动设计」这六个字解释清楚。

领域驱动设计学习资料现状

领域驱动设计的概念提出已经有20年的时间了，整个互联网充斥着大量书籍、文章和视频教程，这里我列举几本比较著名的优秀书籍：

首先不可否认，这些书籍都是优秀的作品，也被业界奉为宝典级别的作品，网上大部分资料的核心内容也都是类似的，但我相信，大部分人读这些资料的感受是：

为什么会云里雾里不明觉厉？

首先，我先列举出了大部分文章提到的概念名词：

目前主流的领域驱动设计资料（书籍、文章、课程），都在尝试将这些概念给读者讲明白，都在尝试解释这样的方法是好的方法，但很显然都没有站在一个不懂领域驱动设计的开发者角度来讲解，要理解这些资料所讲述的观点，是需要先理解「领域驱动设计」，然后才能看得懂，甚至出现领域建模需要「凭经验」这样的说法。

所以说目前大部分的资料，懂领域驱动设计的人才能看懂，而懂的人，又不需要通过这些资料获取养分，这就变成了一部分人的自娱自乐。

由于大部分人在了解领域驱动设计的过程中，更多的感受是「晦涩难懂」、「不明觉厉」，导致整个软件行业对它产生了两级分化的评价，一部分人认为领域驱动设计完全没用，不可落地，一部分人却认为这是软件工程困境的解药，而且处于这两极的开发者，不仅观点无法调和，甚至在辩论过程中，也是驴唇不对马嘴，完全无法在一个频道上沟通和交换观点。

领域驱动设计到底是什么？

// 全网第二个把 DDD 说明白的视频https://www.bilibili.com/video/BV1AZ421M7zw

先说观点： 领域驱动设计 是一种价值观 。

领域驱动设计不是方法论，不是软件设计时的思想指导，不是代码组织的灵丹妙药，它本质上是一种价值观，是你做一个决策时的价值取向。

接下来，咱们把「领域驱动设计」这六个字拆解出来分析。

首先什么是「领域」？英文原词就是「Domain」，这个词并不抽象，就是其直接的含义，就是边界、范围的意思。比如一个篮球场的范围，一个国家的领土范围，一个公司前台的工作职责范围，又或者是一个软件系统提供的功能的范围。

然后是「驱动」，怎么理解呢？我们看看下面几句话：

这三句话的句式是类似的，解读起来就是：工作的目的是赚钱，所以赚钱这个目的驱使我们工作，我们世俗的欲望驱使我们求偶，那么识别（问题、解决方案）的范围/边界这个目标驱使我们进行分析和设计行为。所以「驱动」的意思是为了xx的目标而做yy。

最后是「设计」就是指我们分析需求、设计模型、组织代码的行为。

到这里，「领域驱动设计」这个词表的的意思，就是我们做软件设计的核心驱动力，就是识别各种各样的范围和边界。如果你认同这个观点，就意味着你认为「识别领域」是软件设计的核心目标，是软件设计最重要的事情。

什么是最重要的事？就是你的价值取向，就是价值观。而价值观又恰恰是人们做各种决策的底层因素。

这里举个例子，有的人出门喜欢打车，图方便，方便就是ta看重的价值，有的人出门喜欢自行车，可以锻炼，锻炼就是ta看重的价值，看重不同的价值，在做「选择交通工具」这个决策时，起了决定性作用，最终做出的决定也是不同的。

因此，我们认为价值观决定了做决策时看重什么，而「领域驱动设计」的价值观，就是识别领域是最重要的事，我在分析业务、建模过程中，一定要识别出范围和边界，不识别出来我就不舒服。

当然也有很多与「领域驱动设计」不一致的价值观，比如为了赶工期，「这块没搞清楚，先凑合一下，以后再说」，也是一种常见的软件设计价值观的体现，这是「工期大于一切」的价值观。

当然，很多人会说把需求完全分析清楚也是不现实的，诚然这个是没错的，因此「领域驱动设计」追求的领域的「明确性」，而不是「正确性」，只要我们在做决策的时候，明确哪部分范围是确定性的，哪部分范围是模糊的，模糊的部分当下被我们明确地划分到了哪个部分范围内。毕竟老板、产品经理、研发都是在有限地信息下做决策，不可能全知全能，一定有一部分地决策是做一定地预判，只要我们明确地知道不明确的部分处于怎样地范围即可，未来随着信息的越来越充分，不断修正我们对领域划分的决策即可。

为什么这个价值观符合软件设计的价值利益

// 为什么 DDD 符合软件设计的价值利益https://www.bilibili.com/video/BV19b421H7wc

首先，先来思考一个经典问题：「把大象放进冰箱，一共需要几步？」

第一步，打开冰箱门；第二步，把大象放进去；第三步，关上冰箱门。

我们在解决任何问题的时候，都会遵循一个模式：「大问题拆成小问题」。

而这个模式等价于：「复杂问题变为简单问题」。

那么最关键的问题来了，如何衡量「复杂」和「简单」？我们来看几个例子，下面两个系统，你觉得哪个更复杂？你一定会选「系统2」，因为显然它的元素数量更多。

下面两个系统呢？是不是感觉「系统3」更复杂？

基于上面的例子，我们至少可以得出两个判断：

1. 系统复杂度与元素的数量和元素的关系有关；

2. 元素的关系对系统复杂度的影响远远大于元素的数量所产生的影响；

   

回归到领域驱动设计，为啥要划分领域？因为「划分领域就是在用数量简化关系」，用明确的边界将问题拆解，逐个击破。其意图是控制系统复杂度，尽可能降低系统的复杂度，而复杂度的降低，是与我们软件工程的投入产出利益一致的。

到此，我们就形成了一个核心逻辑链条：「划分领域->降低复杂度->降低成本」，因此划分领域符合我们价值取向，我们愿意认同「领域驱动设计」的价值观。

重新审视对待「领域驱动设计」的分歧

假如你认同「领域驱动设计是一种价值观」这样的观点，我们重新来回到前面说的「完全没用，不可落地」和「软件工程困境的解药」这两派观点的分歧上，就会发现大家的分歧底层就是价值观的分歧，一方面大家的讨论维度都停留在「领域驱动设计怎么落地」这个层面，缺少了「领域驱动设计到底是什么」这个问题的共识；另一方面大家没有察觉到核心分歧其实是价值观的分歧，导致了对于「领域驱动设计」的理解和判断过程缺乏底层认知的共识。

对于本质没有共识，其之上的所有讨论如同「空中楼阁」，缺乏严密逻辑链条的推导，那么表达者不得不用一些抽象的概念来模糊化自己表达的东西，从而使得「领域驱动设计」这个词变得越发抽象，越发「不明觉厉」。

后续

本文从why的角度解析了「领域驱动设计」，并未涉及到How的部分，但以我的经验来看，理解了why，在执行How的操作时会更加地笃定和自信，更容易成功。

且听我后续慢慢道来。