[续]解密广发证券谭德志的“解密DDD”文章

解密广发证券谭德志的“解密DDD”文章>>

截屏2

①古语云，修行需道术并重

“古语”的主要论证手段是类比。在软件开发的研讨中正儿八经地以“古语”为论据，子曰什么什么，所以做软件的时候应该什么什么——这是不是合适的，读者可自行判断。

上一篇“解密”文章我已经引用过的：

★《软件方法（第3版）》第1章（umlchina.com/url/softmeth2024.html）：

DDD已经在和国学合流。

张逸老师在2022年5月提出了“设计国学”的概念，要把软件设计（不是软件界面）和国学结合起来。

★设计国学，软件设计感悟（https://mp.weixin.qq.com/s/Y0fOOQAGNs1ZbNPFipVhMg） 

我在2023年1月就曾预测DDD会和穿越者之友王守仁合流：

★从弦理论谈DDD（https://mp.weixin.qq.com/s/FTD1C9SVWxonyYmmLvs5FA）

2024年9月，张逸老师发表《我的领域驱动设计心学》：

★我的领域驱动设计心学（https://mp.weixin.qq.com/s/RumFL8PwuPec3qhibD1v_Q）

受DDD圈子启发，我也写了一些文章，表示大力支持。并提出了以下有助于缓解当前就业压力的建议：

国内的程序员数量已经接近1000万，可以按比例为程序员配备软件国学顾问，让文史哲专业的同学也加入到信息化建设的大潮中。

★软件开发的山顶是国学和DDD（https://mp.weixin.qq.com/s/1Ff8XghIjWxTzzDPBR6OHg） 

★浑元形意太极的本质是领域驱动设计（https://mp.weixin.qq.com/s/CcTJCSs2WIaEX3DVA5i7XA） 

★马老师浑元十三刀本质是DDD程序=算法+数据结构（https://mp.weixin.qq.com/s/-MRiHrh5uH4Mo2icIuAU4w）

②分享个人对DDD的独到见解

个人见解 不等于 独到见解。

个人见解是：我说说我的看法。

独到见解是：我说出了大多数人说不出来的内容——盲生，我发现了华点。

另外，“独到见解”一般是称赞别人的——“感谢***的独到见解”，很少有“我说一下我的独到见解”。

当然，以上汉语细节不是本文探讨的主要问题，只是顺便提一下。

③领域模型可成为软件项目通用语言的核心。——《领域驱动设计》. Eric Evans

（1）其实原文不是这样

这句话的原文是：

the domain model can provide the backbone for that common language

领域模型可以为这个共同语言提供骨架

可惜，2005、2010、2016中译本写的都是“核心（core）”。其中2005中译本的锅我要背一大部分。

（2）“通用语言”是个伪创新

我在《软件方法》第8章做了详细的阐述：

★《软件方法（第3版）》第8章（umlchina.com/url/softmeth2024.html）： 

注意1998年Catalysis方法这本书，上面划红线的地方：

在Catalysis中，类型图是术语表的核心部分--它们代表着专有术语的词汇表，并明确了这些术语之间的关系。该词汇表可以用于项目的所有相关文档,也可以用在程序代码里。

原文是：

In Catalysis, the type diagrams are the central part of the glossary: they represent a vocabulary of terms, and make plain the important relationships between them. That vocabulary can then be used in all the documents surrounding the project, and in the program code itself.

和Eric Evans的“领域模型可以为这个共同语言提供骨架”是不是很像？

《解密DDD》的作者谭德志要引用“核心”，可能引用这个更合适。

从《软件方法》第1版开始，我就把《UML对象、组件和框架--Catalysis方法》作为推荐书目，当然是推荐读原版“Objects, Components and Frameworks with UML - The Catalysis Approach”，感兴趣的读者可以在认真阅读后，再和DDD圈子的那些产出对比一下。

再看划红线处的“大多数分析者和设计者都很熟悉创建项目词汇表的观念”，说明这是更早时间已经被广泛使用的项目实践。

（3）领域模型呢？他们只是喊口号！

好吧，暂时抛开“通用语言”长得像术语表、“领域模型为这个共同语言提供骨架”长得像“类型图是术语表的核心部分”这些不谈。

关键是，你的领域模型呢？

DDD圈子产出的文献几乎没有合格的领域模型。有个合格的类图、状态机图，或者E-R图也行啊！可惜，没有。绝大多数是词汇的简单罗列：

★京东云开发者DDD妙文欣赏（https://mp.weixin.qq.com/s/lU-PSXHTyVORIcUuvelnRw）

★DDD通用语言、多尿和尿频-《分析模式》漫谈41

（https://mp.weixin.qq.com/s/HKLpwS-St61WZoyyDiltmA）

★Eric Evans这样画是真不懂还是有特别考虑（https://mp.weixin.qq.com/s/TI-rFEuZXLouavZZ1_TBtQ）

这些年我写了那么些文章批评DDD和DDD圈子，其中内容有没有错误呢，大概率应该是有的。

但并没有DDD圈子的人从建模的角度反驳我的文章内容，答案很简单：如果一个人真的有了那个水平，他也就不会相信之前相信的这些东西了。

★你的医书是假的（https://mp.weixin.qq.com/s/PbzMuEXhf1iuAWF5n4ezTQ）：

★《软件方法（第3版）》第1章（umlchina.com/url/softmeth2024.html）：

能指出问题的，是认真研究建模的非DDD圈子同学：

★关于《评“状态和事件本质相同”》的6个疑问（https://mp.weixin.qq.com/s/e8XSGrS2bfnnliW34zZnbA）：

待续，接下来内容有：

④形成一套共通语言

DDD通用语言掩盖了开发人员无能和懒惰，是一种倒退。

⑤工程人员可能只关注ER图、UML等描述工具

UML我已经说得太多，就单拿E-R图来说。

凡是轻飘飘地就批评E-R图（或类似表示法），想踩着它们出名的，作者大概率没有画过一张合格的稍微复杂的E-R图，只是基于“政治正确”这么轻飘飘地说一下。

如果了解E-R图（或类似表示法）的历史，会知道，DDD圈子根本没有资格批评E-R图，反而是E-R图更有资格把这些批评扣回到DDD圈子头上。

我开始写DDD批评系列文章，就是因为反击一篇类似这样轻飘飘批评UML的DDD圈子文章。