# 不同的声音
DDD在2003
年由Eric Evans提出,至今已有将近二十年。自从它提出至今,它没有像Spring
这类工具、MVC
这类架构思想红遍大江南北、融入每一个程序员的日常工作。
对于它的这个现状,不同人有不同的见解。
一些人认为在二十年这么长时间里,都没有发展起来的DDD,主要是因为它并不能如它所宣称的那样,解决问题。认为它是糟糠,没有太多价值。虽然它的名字不断被提及,无非是一些高级开发的炫技或者其他吧啦吧啦原因而已...
但也有一些声音,之所以经过二十年还在不断的被提及,正说明了它的价值所在:蕴藏着解决问题的方法。那为什么一直不温不火呢?是因为太复杂了,导致掌握它的人比较少。但实质上它确实能够解决一些业务问题,因此各方豪士才对它不断发起攀登,希望成为专业的DDDer,只是路上因为太难了放弃的人太多了...
对于我本人,我是比较赞同第二个观点的。
那么,DDD具体解决了那些问题了呢?又为什么难掌握呢?
# DDD具体解决了那些问题
首先,在DDD中得到解决的问题毋庸置疑是它的价值。此外,在DDD中提出了但没有解决的问题,其实也是DDD的价值,因为他把问题分析并暴露出来了。
在DDD中得到解决和暴露的问题主要有如下一些:
面对软件开发中常常出现的鸡同鸭讲信息丢失,提出了一种沟通协作方式。拉通业务、产品、研发、测试统一业务语言,通过统一的手段降低壁垒、提高效率。
下面这个案例,就是因为没有统一语言,导致的业务需求和实际产出物不一致。而DDD的统一语言,就是解决它的利器。
DDD将业务系统间的解耦更加的明确和工具化。通过限界上下文映射图、防腐层及对应的实战工具:共享内核、开放主机等工具,将原有业务系统的强耦合进行了剥离。极大的降低了所要处理系统的复杂度,提高了系统开发的成功率。
虽然现在主流的编程语言基本上都是面向对象的,但现状是,大部分的代码都是面向过程的,根本没有使用到语言本身的各种功能。DDD中的实体、值对象等概念正好符合面向对象的概念,它强调行为和属性内聚到对象里,以充血模型的方式进行思考、设计。采用DDD的思想,可以将贫血模型的编码方式,转变为更贴近现实、更符合语言设计初衷的面向对象的方式。
......
# 为什么难掌握
虽然DDD解决了不少软件开发中的问题,但DDD的概念却被不多的开发者所掌握。究其原因,我觉得主要有以下几点:
DDD是一种方法论,而不是一种工具实战手册。方法论是一种高度抽象的理念,需要不断实践才能领悟和掌握。
通常,实战手册是非常明确的,但应用场景却非常有限。如针对如何配置
tomcat
支持https
,文档查阅之后,按照步骤你即可完成配置。但针对这种经过抽象的方法论,你阅读完之后,面对实战:按DDD设计一个电商系统,你仍然不知道如何下手。主要原因是,实战手册只针对具体确定场景,也只能解决那一个问题,落地的每一步都比较确定。而方法论是是从多个类似的问题和解决方案场景抽象而来,能够解决此一类问题。它以概括性的方式进行描述,但具体应用需要你自己根据场景相似度去拿捏。
第二点原因是DDD的官方书籍讲的不够细节或者说案例偏少,这可能也是方法论的问题所在。作者不可能把所有案例都穷举一遍,但人对具象(如工具手册)的知识容易理解,抽象的内容难以掌握。这也就是DDD难以被掌握的原因之一吧。
最后应该是DDD的一篮子概念确实有点多。共计有大概12个概念项,在战略建模上有3个:通用语言、限界上下文、上下文映射,战术建模上有实体、值对象、领域服务、领域事件、聚合、模块、工厂、资源库、应用服务。这么多概念也是DDD难以被掌握的原因之一。