软件方法（下）第8章分析之分析类图—知识篇Part05（202205更新）领域专家和通用语言

DDD领域驱动设计批评-文集-点击查看>>

《软件方法》强化自测题集-点击查看>>****

8.2.4 类和属性的命名

8.2.4.1 使用严谨的领域术语命名领域模型中的元素

领域模型中各个元素的名称尽量来自该领域的术语体系。

一个领域之所以能作为“领域”为人认知，必定会在发展过程中沉淀出一套日益完善和精确的术语体系。每个术语有其独特的、其他术语不能替代的含义。

例如物理学中的质量、重量、重力、引力、衰变、裂变、聚变……，各自有各自的含义，不是另一个概念可以取代的。

涉众习惯的用语不一定是严谨的领域术语

也许是出于自己的知识局限，或者出于字数少使用方便，涉众有时习惯于使用一些不严谨、感性的用语，这些用语不一定适合用来命名领域模型中的元素。

这些用语经常会用颜色、大小等感性认识来称呼领域概念。例如，货车司机可能会把一张单子称为“绿单”，因为单子的颜色是绿色的，但更精确的名称可能是“送货单”；购物时的“小票”，名称来源于面积较小（和面积更大的“发票”比较），更精确的名称可能是“收据”。

这些用语所依赖的信息，稳定性往往比真正的领域内涵要差。有关机构可以改变送货单的颜色，购物收据也可以变成面积比发票要大的大长条，“绿单”、“小票”等用语就不再合适了。即使已经形成了习惯不得不一直沿用下去，真实的情况和字面的意思已经大相径庭。

涉众喜欢用不严谨的用语，这是正常的。某类涉众的领域知识可能会很片面，对领域概念认识不深刻，怎么能寄望一个使用探探来交友的屌丝青年清楚社交六度空间理论呢？正如第7章所说，涉众关注的是涉众利益，不能指望涉众提供需求，更何况是分析了。精确使用领域术语是建模人员的责任，不是涉众的责任。

同一领域概念，不同涉众可能会有不同的习惯用语

例如：老鼠-耗子、马铃薯-土豆、祖母-奶奶、宝贝-商品、购物-买东西。

如果怀疑两个用语描述的是同一个概念，可以这样问：有没有不是商品的宝贝？有没有不是宝贝的商品？如果回答都是否，就清除掉其中一个，否则，应该继续研究两个用语背后的真正含义，必要时在模型中表达其中差别。

如图8-51，左侧的几个概念中，经过审查，认为"宝贝"和"商品"、"顾客"和"客户"含义相同，去除其中一个；“用户”、“顾客”、"会员"含义有差别，在类图上更精细地表达。

图8-51 清理冗余的用语

当然，在和人类执行者交互的界面上，针对各自的习惯，依然可以使用不同用语如“宝贝”、“商品”称呼同一概念。

也可以对“同一概念不同涉众用语不同”这部分知识建模，以备在界面上使用，如图8-52。上面提到的“宝贝”、“商品”就成为了“用语”类的对象。

图8-52 建模“同一概念不同用语”

图8-52中所描述的类以及类之间的关系适用于各个领域，和某个特定领域并不相关，因此不要把这部分知识和特定领域的知识混在一起。假如建模成图8-53，就搞混了“是一个”和“有一个”的区别，又变成废话刷工作量了。在后面“识别类的关系”内容中会再详细讲述。

图8-53 “同一概念不同用语”的错误建模

领域专家

建模人员除了和各类涉众交流，还需要从领域专家那里获取严谨的领域知识和领域术语。

首先要提醒的是，“领域专家”这个词已经被严重污染。

很多人把“经验较多的涉众”当成了领域专家，例如跑运输多年的老司机，例如通过某社交软件约了几百人的老司机。但正如上文所述，这些涉众不一定是领域专家，他们也许能提供丰富的素材，但未必能严谨表达和深入思考。

领域专家要能够从研究学问的角度来看待他所在的领域。他应该有该领域比较扎实的基础知识，经常阅读该领域的最新文献，了解该领域当前研究进展。领域专家可能是该领域的“研究人员”，至少也是该领域的“科普人员”。

“研究人员”、“科普人员”加了引号的意思是他们不一定要有“教授”、“研究员”、“老师”等正式的职位，但至少满足上面所说的要求。当然，上面提到的货运老司机、社交老司机等涉众如果能深入研究自己所在领域的学问，也可以成为领域专家。

领域专家很可能并不是涉众（当然也可以是）。例如，为A公司开发供应链系统，建模人员可以向B高校研究供应链的学者领域知识。学者是领域专家，但他可能跟A公司没有关系，这个系统最终会是什么样子，也不涉及到他的特定利益，他并不是涉众。

如果有条件，建模人员可以和领域专家直接交流，借助领域专家的指点，尽快得到确实反映领域内涵的模型。如果没有条件直接交流，可以通过阅读领域专家的各种产出，间接获得帮助。

上文也提到，领域的术语体系是日益完善的。在熟练掌握领域现有术语体系的基础上，辅以严谨的建模技能（背后是一些数学思想），建模人员可以起到“反哺”的作用——帮助清理领域当前术语体系中存在的冗余和矛盾并改善。注意其前提条件：熟练掌握现有术语体系+严谨的建模技能，这不是随便就能达到的！

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也算，“通用语言”哪里有？术语集或术语表的称呼更合适。
微信:umlchina2