关于DDD,我知道的…

关于DDD,我知道的…

《关于郑州的记忆》- 李志

最近看完了五本关于DDD(领域驱动设计)相关的书,阅读顺序和成书的时间顺序一致,分别是:

  • 《企业应用架构模式》 Patterns of Enterprise Application Architecture 作者 Martin Fowler
  • 《领域驱动设计》 DDD 作者 Evans
  • 《实现领域驱动设计》 IDDD 作者 Vernon
  • 《领域驱动设计精粹》 作者 Vernon
  • 《领域驱动设计(ThoughtWorks洞见)》,由ThoughtWorks中国的博客汇编而成

再次感叹ThoughtWorks的人对于业务开发的思考和沉淀之多,五本里面有两本都出自它们的员工;并且也是我最喜欢的两本。

不过即使看完了以上五本入门书籍,我还是要说:关于DDD,我知道的不太多。

这五本书在领域驱动设计这个概念上有一种一脉相承的感觉,Martin Fowler的《企业应用架构模式》成书最早,中文版在04年就出版了,在这本书里,他对复杂业务架构的一些思考,被Evans、Vernon频繁引用,某种程度算是DDD的先驱了。他对于贫血模型、充血模型的阐述很经典,不过由于成书太早,这本书其实已经比较过时了。我这里也引用一句他老爷子的话:

I found this (business logic) a curious term because there are few things that are less logical than business logic.

这句话太可乐了。多少业务开发笑着笑着就哭了。

以前我觉得做游戏开发 = 策划的翻译机器,现在我看明白了,web后端开发 = PM的翻译机器这条也成立。贫血模型会有失忆症,这里的失忆症不仅仅是代码上的,是指开发和PM的,逻辑复杂化以后,谁还记得当年某天某个犄角旮旯里的弯弯绕绕呢。PM和开发面对某个bug,一脸茫然、面面相觑,心里可能同时在想:“其实这个吧,也不能都赖他”。这是一个很大的问题。我觉得其实MVC或者MVCS的框架挺好的,简单实用,只要你愿意加时间,什么恶心的逻辑写不出来?没有什么逻辑是在service里面写1000行代码解决不了的,如果有,就再写1000行,如果还不行,那就加个中间件吧。策划至少还给你把逻辑写清楚,你能指望PM把逻辑规则给你写清楚吗?写清楚以后,出了问题还能找谁背锅?都是打工人,有一些模糊空间,可能大家都乐见其成。只不过有一些是主动模糊的,还有一些,是被动遗忘导致模糊的。

Evans觉得MVC最大的问题是在业务复杂度上来以来不便于维护,为此他和Vernon俩哥们还扯了一些乱七八糟的评价指标,用来判断一个业务项目是否符合使用DDD的标准。没有任何统计数据支撑的指标一律都是胡扯。DDD和IDDD里面有大量这种内容,俩老哥们也真是煞费苦心,编这么些篇幅,其中Vernon更过分,在IDDD里面写一些玄而又玄的东西,每一篇的篇头写一句莫名其妙的名人名言,每一篇的结尾写一些美国牛仔的胡言乱语,故弄玄虚,平添阅读过程中的顿挫感,也有可能是翻译的失误,总之DDD和IDDD的一些内容不是非常的读者友好。(小小吐槽一下)

不过DDD的解决方案,逻辑上是自洽的。代码维护的问题,用改变代码组织方式的思路去解决是合理的。就好比图书馆里的书,原先是平铺在地上的,现在我分门别类放架子上,以后书再多,也不至于手忙脚乱,代码也是一样,用聚合根,把逻辑相关的代码组织在一个模块下,就便于后续维护了。怎么才算逻辑相关呢?属于一个领域的,就是逻辑相关的,于是Domain Drived Development呼之欲出。接着就是实体、值对象、领域服务、CQRS、Event sourcing、领域事件这些配套概念。

解决问题的方法越多,引入的新问题也越多,对于这些概念,其实还有很多疑问,可能需要在实践中去解决,我百思不得其解的有:

  1. 怎么区分值对象和实体对象的使用场景,实际应用的时候是不是需要严格区分这两类对象的使用
  2. 怎么界定领域服务的场景
  3. 事件回溯的成本与必要性是否成比例
  4. 聚合根与限界上下文是不是一对一的关系,会不会存在一对N,N对一,甚至N对N的情况
  5. 最重要的,DDD真的是应对业务复杂度的终极解决方案吗?

美团的技术分享都做的很朴素直白,https://tech.meituan.com/2017/12/22/ddd-in-practice.html ,它们的这篇分享是一个了解DDD落地的有益补充。

只想说,关于DDD,我知道一些,只是做的很少(狗头)。

发表评论