这是在知乎我的一篇文章《更狂野的新一代DDD布道师来了》（https://zhuanlan.zhihu.com/p/1909238315825206249）下的评论。该文首发微信公众号，同时发到知乎。
在文章中，我批评某新一代“DDD布道师”不调查研究就胡乱发言。文章主题并不是UML，这位root却在文章下连发三条针对UML的评论，这是非常值得探讨的。
一、关于这三条评论的猜测
首先声明，我不认识root。这不是我们派一个人故意反串，发布漏洞百出的言论，借此抹黑DDD饭圈。
另外，我也没有和该“DDD布道师”直接打过交道，也无意和他直接沟通。
根据以往的经验，我大胆猜测：
（1）root必定和该“DDD布道师”有关系。
（2）root不是该“DDD布道师”本人。
理由一：
这里面的逻辑混乱比起我之前批评的“DDD布道师”的逻辑混乱更严重。
理由二：
该“DDD布道师”自己也画UML类图，不至于说出这样的言语。
（3）root可能是该“DDD布道师”的饭圈成员之一，互相知道对方的存在。
（4）root在8月6日发表这些评论之前不久，可能有人发表过针对我的言论，被这位root看到了。
理由：
我批评该“DDD布道师”的文章发表于5月份。该“DDD布道师”以及饭圈应该是知道的，很可能已经在饭圈内群情汹涌，纷纷表态过了。随后，我没有再写文章批评该“DDD布道师”。
隔了一段时间，在8月6日突然又发这么一个，应该是有引发源的。可能是有人旧事重提，于是饭圈成员心情激动，寻过来发评论。
以上仅是我的猜测。
二、评点root的言论
首先，还是说过很多很多遍的话：
但凡发言之前稍微做一下调查研究，哪怕是搜一下**百科的词条，也不至于内容写成这样；
如果认真看一下《软件方法》第1章（umlchina.com/url/softmeth01.html），绝大多数“反UML”的言论也就说不出口了。
可惜，很多人是不会去做的。
下面，我们一句一句来看root写的评论。
（1）UMl的标准05年就没有任何更新了
2005年之后，UML规范更新了7次。
UML规范的最新版本是2.5.1，发布于2017年12月。从这个时间看，确实是好些年没更新了。同样，SysML 1.6发布时间是2019年12月。这两个看起来是到了一个瓶颈。
解决方案大家都知道了，是最近被OMG接纳为标准的SysML v2。
（2）IBM的RUP专家证书，UML的专家证书15年就停止发布了
UML是开放、独立于厂商的标准，官方证书是OMG Certified UML Professional (OCUP)，现在依然可以考。以下是Pearson VUE的OMG证书入口（https://www.pearsonvue.com/us/en/omg.html）：
按道理， IBM是不会颁发“UML证书”的，因为UML不属于IBM。
我去查了一下，IBM发过这样的证书（https://www.ibm.com/training/certification/ibm-certified-solution-designer-object-oriented-analysis-and-design-vuml-2-38006003）：
名字是“IBM认证解决方案设计师-面向对象分析设计，UML2版本”。这个证书是“面向对象分析设计-设计师”认证，只是标明用的建模语言是UML。类似于软考发“程序员”证书，附加一个括号（Java语言）。
注意，我说“我去查了一下”，说明我看到“IBM的UML证书”的说法时，感觉是比较新鲜而且奇怪的。
我又专门查了几个历史悠久而且现在依然活跃的UML工具：
Enterprise Architect（1996-）：其厂商Sparx Systems没有颁发过类似证书。
VP-UML（2001-）：其厂商Visual Paradigm没有颁发过类似证书。
Astah（Jude）（1996-）：其厂商Change Vision没有颁发过类似证书。
MagicDraw（1995-）：其厂商No Magic、Dassault Systèmes没有颁发过类似证书。
至于为什么IBM提供，后来又停发“IBM认证解决方案设计师-面向对象分析设计，UML2版本”的证书，不得而知。
*IBM只是提供UML建模工具的厂商之一
根据UMLChina统计，UML建模工具最多时有168款，目前仍有几十款在持续更新。UMLChina每三个月会把最近更新的工具信息发在umlchina.com/url/tools.html。
2003年，IBM收购了Rational，然后推出了一款基于Eclipse的UML建模工具Rational Software Architect（RSA），不再沿用Rational Rose的名称，原来的Rational Rose在2006年之后不再更新。
这可能是一个错误的决定。
RSA界面风格大变，使得原有的Rational Rose用户（包括我）纷纷转向用起来更像Rose的另一款UML建模工具，Enterprise Architect（EA）。
当然，也可能高层定位的目标人群变了，不再看得上中小企业。
Rational Software Architect最新版本是10.0，发布时间2025年4月18日，参见：https://www.ibm.com/support/pages/node/7185079#ABOUT。
另外，IBM在2008年收购了Telelogic，获得了另一款建模工具Rhapsody。
Rhapsody自1996年诞生以来，在嵌入式和实时系统领域一直是标杆，在后来的MBSE中也占据重要地位，不过最近几年受到了Dassault Systèmes (达索系统) 的Cameo Systems Modeler (MagicDraw)的冲击。
IBM Engineering Systems Design Rhapsody最新版本是 10.0.2，发布时间2025年5月13日，参见：https://www.ibm.com/new/announcements/rhapsody-10-0-2-revolutionizing-engineering-efficiency
*UML和RUP的区别
RUP（Rational Unified Process）是过程，UML是建模语言，不是一个东西。
以我已经出版了两版（2013，2018）的《软件方法》为例，全书用UML建模，但无一处提到RUP或Rational Unified Process。
（3）IBM 这种靠各种证书的
IBM怎么成了靠各种证书的了？
要说证书，过去二十年，思科、Oracle、微软包括软考都比IBM证书要更普遍和管用吧？近些年，更多听说的是华为证书、阿里云证书。
（4）现在互联网的瀑布流，快速迭代，uml可以实现吗？
瀑布流说的是网页布局？还是说瀑布+迭代？和“uml可以实现吗”有什么关系？
（5）建议好好去了解uml出现的时代和解决的问题
几本出名的UML书籍中译本封面都有“UMLChina”字样，这位同学让我去好好了解UML出现的时代和解决的问题。
（6）uml最开始的图，可以支持文本搜索吗？这最基本的缺陷你能直视吗？
这位同学该不会以为，建模工具在存储UML模型的时候，存储的就是一张张的图片吧？
以EA为例，本地存储最开始使用Microsoft Access（.eap、.eapx），后来支持Firebird（.feap），从EA16开始，缺省为SQLite（.qea、.qeax）。服务器存储支持各种数据库：Microsoft SQL Server、Oracle、MySQL、PostgreSQL、MariaDB……
还“支持文本搜索吗”——EA的各种插件都玩出花了，最开始使用VBA，后来支持JavaScript，有很多商业插件和开源插件。
（7）现在各种渲染语法，你可以统一吗？虽然现在开始让uml支持文本了。
这里应该是指PlantUML、yUML、Mermaid等。
一段PlantUML脚本可以看作一段生成图形的批处理命令，起到的效果和在图形界面建模工具中点击和拖动类似。
要得到形状接近的图，输入一段文本，PlantUML和Mermaid有差别；通过图形界面操作，EA和StarUML的操作序列有差别。
UML没有规定建模时的输入方式，可以是点击、拖动、文本命令、用笔绘画、声音、动作（例如，用浑元太极的接化发和闪电五连鞭招式作为输入方式）……
此处和上一个知识点有相似之处，不要把输入方式、图形展示和模型存储混淆。
UML规范没有规定模型的存储方式，但规定了可视化建模时图形的形状，这有时让人误解成这个图形就是模型，其实图形是次要的。
判断一个东西算不算UML建模工具，是看它有没有封装UML元模型的逻辑。如果封装了元模型的逻辑，即使没有图形界面，它也是建模工具。反之，有可能只是一个在视觉表现接近UML图形表示的绘图工具。
OMG制定了XMI（XML Metadata Interchange，XML元数据交换）规范，A工具的模型可以转成XMI文件，然后导入B工具。主流的UML工具都有这个功能，只不过有的厂商喜欢在里面加一些自己的东西，导致其他工具导入时不能完全转换。
（8）uml的状态机，随着软件的复杂度提升，代码复杂度可以轻易增加，毕竟是文本，uml只能各种魔法值缩写来代表了。能跟上软件的发展吗？
这段没看懂是什么意思。
意思是不是说，软件复杂度提升了，如果是写文本代码，继续往下写就是了。如果是用UML状态机表示，画布（想象了一幅无法扩展的画布）装不下（文本怎么就不担心装不下？），然后命名也不能好好命名了，为了压缩空间，只能用缩写？
我们先不说 “软件的复杂度提升，代码复杂度可以轻易增加，毕竟是文本” 这样看待复杂度的观点对不对，只说一点：
这跟UML状态机，跟UML有什么关系？所有的文本 vs. 图形，包括电路图、建筑图等都有这个问题啊！
我反对画电路图，随着电路复杂度提升，如果用文本表达，可以轻易增加文本，用电路图表达，空间不够大怎么办，只能用魔法缩写来代表了。
以下摘自《软件方法》第1章：
相对于只有自上而下顺序的文本（包括自然语言文本和编程语言文本），能够朝四个方向扩展的平面图形（如果有三维模型就更好了）更容易让建模人员看出概念之间的联系。例如，图1-9和图1-10的内容，如果没有图形的帮助，通过文本一行一行地构造和阅读模型，人脑的负担非常重。
另外，你们不是鼓励糊墙吗？能忍受满墙的事件风暴废话，UML状态机图大一点就受不了？
不客气地说，除非是故意刷废话，否则以贵圈的这点能力，能真正建模软件复杂度，得到一个布满PC屏幕且肉眼识别的模型图，怕是不太容易。
结语
我写DDD领域驱动设计批评系列文章已经6年多，最开始是由张逸老师文章而起，后来又批评了一些Thoughtworks公司的同学。
现在，他们都很少谈领域驱动设计了。新一代的领域驱动设计圈子是这样的水平，不知道张逸老师他们作何感想。
扫一扫
3758
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
