关于领域驱动设计,大家都理解错了(领域驱动设计的主要核心概念)

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

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

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

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

  • 领域驱动设计之父 Eric Evans《领域驱动设计-软件核心复杂性应对之道》

  • Vaughn Vernon的《实现领域驱动设计

  • 张逸老师的《解构领域驱动设计》

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

  • 晦涩难懂

  • 不明觉厉

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

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

  • 问题空间(problem space)

  • 解决方案空间(Solution Space)

  • 领域(Domain)

  • 限界上下文(Bounded Context)

  • 通用语言(Ubiquitous Language)

  • 实体(Entity)

  • 值对象(Value Object)

  • 聚合(Aggregate

  • 仓储(Repository)

  • 工厂(Factory)

  • 领域服务(Domain Service)

  • 领域事件(Domain Event)

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

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

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

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

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

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

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

接下来,咱们把“领域驱动设计”这六个字拆解出来分析。

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

关于领域驱动设计,大家都理解错了(领域驱动设计的主要核心概念)

然后是“驱动”,怎么理解呢?我们看看下面几句话:

赚钱驱动工作

欲望驱动求偶

领域驱动设计

关于领域驱动设计,大家都理解错了(领域驱动设计的主要核心概念)

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

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

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

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

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

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

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

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

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

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

首先,先来思考一个经典问题:“把大象放进冰箱,一共需要几步?”

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

我们在解决任何问题的时候,都会遵循一个模式:“大问题拆成小问题”。

关于领域驱动设计,大家都理解错了(领域驱动设计的主要核心概念)

而这个模式等价于:“复杂问题变为简单问题”。

关于领域驱动设计,大家都理解错了(领域驱动设计的主要核心概念)

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

关于领域驱动设计,大家都理解错了(领域驱动设计的主要核心概念)

下面两个系统呢?是不是感觉“系统3”更复杂?

关于领域驱动设计,大家都理解错了(领域驱动设计的主要核心概念)

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

系统复杂度与元素的数量和元素的关系有关;

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

关于领域驱动设计,大家都理解错了(领域驱动设计的主要核心概念)

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

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

重新审视对待“领域驱动设计”的分歧

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

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

后续

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

且听我后续慢慢道来。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

(0)
上一篇 2024年7月8日 上午11:11
下一篇 2024年7月8日 上午11:23

相关推荐