关于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,我知道一些，只是做的很少(狗头)。