《软件方法》强化自测题集>>
《软件方法》各章合集>>
8.2.4.2 关于DDD话语中的“通用语言”
DDD（领域驱动设计）话语中有“通用语言（Ubiquitous Language）”的用语，这是一个伪创新。
（1）类似“通用语言”的概念早已有之。
“术语表（Glossary）”或“数据字典（Data Dictionary）”等内容，几十年前的开发规范中应该就已经有了。
下面是出版日期在Eric Evans的《领域驱动设计》之前的几本书的截图。
图8-54 摘自《软件复用：结构、过程和组织》（Ivar Jacobson等，英文原版出版于1997年）
图8-55 摘自《UML对象、组件和框架——Catalysis方法》（Desmond Francis D’Souza 等，英文原版出版于1998年）
图8-56 摘自《程序员修炼之道——从小工到专家》（Andrew Hunt 等，英文原版出版于1999年）
（2）“通用语言”迎合了呆在舒适区的需要
那么，DDD圈子为什么要重新发明“通用语言”，并强力吹捧呢？
原因就是8.1.8.3 伪创新为什么受欢迎中阐述的：它迎合了“广大开发人员”呆在舒适区的需要。
我们在上文强调，建模人员要虚心学习领域知识，而这是很辛苦的事情，很多人是不愿意吃这个苦的。
“通用语言”妙就妙在它告诉你，可以不用吃苦不用走出舒适区！
我们先来看一下Eric Evans在《领域驱动设计》中对“通用语言”的陈述，如图8-57。
图8-57 摘自《领域驱动设计》（Eric Evans，英文原版出版于2003年）
从图8-57我们可以看到，“通用语言”是“技术术语”和“业务术语”的交集，用本书的话来说，就是“非核心域术语”和“核心域术语”的交集。
问题是，有交集吗？
技术术语（非核心域术语），例如浏览器相关的术语：请求、回应、渲染、DOM、序列化、反序列化……。
业务术语（核心域术语），例如商场相关的术语：商品、顾客、订单、库存、收银、盘点……。
“技术术语”和“业务术语”哪里有交集？莫非是把这些正交的术语随意组合，以达到废话刷工作量的效果？此处可以回顾我们在8.1.3 域之间的映射和协作中关于a×b×c的陈述。
DDD话语中所谓的“技术术语”，根本和“技术”无关，其实只是“技术人员”在没有虚心学习领域知识的情况下编造的“业务术语”——“技术人员编造的业务术语”。
而“通用语言”使得“技术人员”编造“业务术语”变得理直气壮，这是一个大倒退。
现实中，难免会有“技术人员”懒得去调研涉众，懒得去学习领域知识，乱做一通了事的现象。这是人性使然，很难杜绝，但至少我们还知道这样做是不好的，如果要做更好，应该怎么做。
如果把偷懒变成理直气壮，味道就变了。
就像我们说“人是自私的”，这是低调描述一个事实，但如果理直气壮地说“人不为己，天诛地灭”，味道就不一样了。
图8-58是Vaughn Vernon在《实现领域驱动设计》中的陈述：
图8-58 摘自《实现领域驱动设计》（Vaughn Vernon，英文原版出版于2013年）
看，不是业务语言，不是工业标准（Industry Standard，译为行业标准更好）术语，是团队自己创建的。也就是说，同一个领域，开发团队不同，团队里的人不同，所得到的“通用语言”可能就不一样。
观测会影响结果，这莫非是软件开发的“薛定谔的猫”？你有你的物理学，我有我的物理学，本开发团队自有“队情”在，“技术人员”这小日子过得可真是舒坦啊！
更妙的是，“技术人员”还会自我感动。本来我是高大上的“技术”，现在向你“业务”开了个口子，让你也参与进来，你“业务”应该感恩戴德了！
这是一种智力上的优越感所带来的傲慢（当然还有金钱、Quan力，不便展开，就不提了）。
如果某个领域的从业人员的平均智力水平（学历、学校、智商等）不如软件开发行业，那么软件开发人员，即所谓的“技术人员”在面对该领域的“业务人员”时，是有一种优越感的。
这种优越感让“技术人员”在做供应链系统、商场系统时有足够的底气来编造“通用语言”，因为他觉得货车司机、仓管、外卖小哥、商场经理的智力水平不如他。
如果所开发系统的核心域是凝聚态物理、非线性分析之类的，“技术人员”面对智力水平超过他的“业务人员”，这份优越感就不会有了。这时，“技术人员”可能就会虚心去学习相关领域知识，因为他觉得这是一件高大上的事情，有面子！
（3）不要让利益博弈压倒“客观规律”。
有一种论调值得警惕。该论调认为“通用语言”让“技术人员”一方有了话语权，不用受“业务人员”一方主导，不用低三下四地去学习领域知识，这对“技术人员”一方有好处。
这样的论调是利益博弈压倒了领域的“客观规律”，不可取。
如果系统的核心域模型没有准确体现领域的“客观规律”，而是发生较大的偏离，那么最终的结果必然是该系统容易出错或者应变成本很高。这种情况也许对某些摸鱼的开发人员有“多劳多得”的好处，但对于整个开发团队以及涉众来说，肯定是有害的。
注意，上面说的“客观规律”加了引号，意思只是说，这些规律不会受开发团队、实现技术等变化的影响，不代表这些规律符合科学。
最常见的，游戏中的知识体系和各种规律，像王者荣耀中的攻击、防御、移动，是魔法不是科学，但建模人员依然要认真去学习和体会这一套体系中的各种“学问”。
同理，上文提到，建模技能可以帮助清理术语中的冗余和矛盾，但仅止于此，建模技能并不能帮助判断该领域的知识是否科学。
（4）“语言”过于宏大
“通用语言”的“语言（Language）”这个词太大。语言要有自己的语法，汉语算，C算，UML也算，“通用语言”哪里有？术语集或术语表的称呼更合适。
[202205升级知识讲解]23套UML EA和StarUML的建模示范视频-全程字幕
6月9-12晚网络软件需求设计方法学全程实例剖析公开课
《软件方法》书中自测题-题目全文 分卷自测（1-8章）16套111题
《软件方法》强化自测题集110题
CTO也糊涂的常用术语：功能模块、业务架构、用户需求……[20210217更新]
如何选择UMLChina服务
