转载自：https://cloud.tencent.com/developer/article/2011322
作者：潘加宇 (微信公众号UMLChina)
(2)“通用语言”迎合了呆在舒适区的需要
那么，DDD圈子为什么要重新发明“通用语言”，并强力吹捧呢？
原因就是<u style="box-sizing: border-box; list-style: inherit;">8.1.8.3 伪创新为什么受欢迎</u>中阐述的：它迎合了“广大开发人员”呆在舒适区的需要。
我们在上文强调，建模人员要虚心学习领域知识，而这是很辛苦的事情，很多人是不愿意吃这个苦的。
“通用语言”妙就妙在它告诉你，可以不用吃苦不用走出舒适区！
我们先来看一下Eric Evans在《领域驱动设计》中对“通用语言”的陈述，如图8-57。
从图8-57我们可以看到，“通用语言”是“技术术语”和“业务术语”的交集，用本书的话来说，就是“非核心域术语”和“核心域术语”的交集。
问题是，有交集吗？
技术术语(非核心域术语)，例如浏览器相关的术语：请求、回应、渲染、DOM、序列化、反序列化……。
业务术语(核心域术语)，例如商场相关的术语：商品、顾客、订单、库存、收银、盘点……。
“技术术语”和“业务术语”哪里有交集？莫非是把这些正交的术语随意组合，以达到废话刷工作量的效果？此处可以回顾我们在<u style="box-sizing: border-box; list-style: inherit;">8.1.3 域之间的映射和协作</u>中关于a×b×c的陈述。
DDD话语中所谓的“技术术语”，根本和“技术”无关，其实只是“技术人员”在没有虚心学习领域知识的情况下编造的“业务术语”——“技术人员编造的业务术语”。
而“通用语言”使得“技术人员”编造“业务术语”变得理直气壮，这是一个大倒退。
现实中，难免会有“技术人员”懒得去调研涉众，懒得去学习领域知识，乱做一通了事的现象。这是人性使然，很难杜绝，但至少我们还知道这样做是不好的，如果要做更好，应该怎么做。
如果把偷懒变成理直气壮，味道就变了。
就像我们说“人是自私的”，这是低调描述一个事实，但如果理直气壮地说“人不为己，天诛地灭”，味道就不一样了。
图8-58是Vaughn Vernon在《实现领域驱动设计》中的陈述：
看，不是业务语言，不是工业标准(Industry Standard，译为行业标准更好)术语，是团队自己创建的。也就是说，同一个领域，开发团队不同，团队里的人不同，所得到的“通用语言”可能就不一样。
观测会影响结果，这莫非是软件开发的“薛定谔的猫”？你有你的物理学，我有我的物理学，本开发团队自有“队情”在，“技术人员”这小日子过得可真是舒坦啊！
更妙的是，“技术人员”还会自我感动。本来我是高大上的“技术”，现在向你“业务”开了个口子，让你也参与进来，你“业务”应该感恩戴德了！
这是一种智力上的优越感所带来的傲慢(当然还有金钱、Quan力，不便展开，就不提了)。
如果某个领域的从业人员的平均智力水平(学历、学校、智商等)不如软件开发行业，那么软件开发人员，即所谓的“技术人员”在面对该领域的“业务人员”时，是有一种优越感的。
这种优越感让“技术人员”在做供应链系统、商场系统时有足够的底气来编造“通用语言”，因为他觉得货车司机、仓管、外卖小哥、商场经理的智力水平不如他。
如果所开发系统的核心域是凝聚态物理、非线性分析之类的，“技术人员”面对智力水平超过他的“业务人员”，这份优越感就不会有了。这时，“技术人员”可能就会虚心去学习相关领域知识，因为他觉得这是一件高大上的事情，有面子！
(3)不要让利益博弈压倒“客观规律”。
有一种论调值得警惕。该论调认为“通用语言”让“技术人员”一方有了话语权，不用受“业务人员”一方主导，不用低三下四地去学习领域知识，这对“技术人员”一方有好处。
这样的论调是利益博弈压倒了领域的“客观规律”，不可取。
如果系统的核心域模型没有准确体现领域的“客观规律”，而是发生较大的偏离，那么最终的结果必然是该系统容易出错或者应变成本很高。这种情况也许对某些摸鱼的开发人员有“多劳多得”的好处，但对于整个开发团队以及涉众来说，肯定是有害的。
注意，上面说的“客观规律”加了引号，意思只是说，这些规律不会受开发团队、实现技术等变化的影响，不代表这些规律符合科学。
最常见的，游戏中的知识体系和各种规律，像王者荣耀中的攻击、防御、移动，是魔法不是科学，但建模人员依然要认真去学习和体会这一套体系中的各种“学问”。
同理，上文提到，建模技能可以帮助清理术语中的冗余和矛盾，但仅止于此，建模技能并不能帮助判断该领域的知识是否科学。
(4)“语言”过于宏大
“通用语言”的“语言(Language)”这个词太大。语言要有自己的语法，汉语算，C算，UML也算，“通用语言”哪里有？术语集或术语表的称呼更合适。