DDD领域驱动设计批评文集
做强化自测题获得“软件方法建模师”称号
《软件方法》各章合集
我把《软件方法》第1章的内容交给Nano Banana Pro，让它生成漫画。AI生成的漫画如下：
原文如下：
1.3.2.3 自编图形 vs. 标准图形
事实上，纯口头交流甚至纯文本交流是很少见的。除非要交流的问题极其简单或者其他同事对这样的人极其容忍，否则他至少也得随意画几张“草图”来传达自己的意思——自编的图形才是比例最大的存在。
这样的人之所以用自编的图形，往往并不是因为他看出了UML有哪些不足，然后用自己的表示法弥补了这些不足，而是要遮掩背后的一些脓包。
脓包一：利益绑架
项目中，有人画了张自编的图形，然后往往会伴随这样的招呼，“来，我给大家讲讲！”。这意味着项目要依赖于“我”头脑中的隐式知识——要是“我”不给大家“讲讲”，大家就不理解“我”画的图的意思，项目就玩不转了。于是，“我”在团队里的地位就提高了，大家得哄着“我”捧着“我”，领导不敢轻易开掉“我”，“我”提出离职领导还要挽留。这在有一定资历、但又不对项目的成败承担首要责任的“高手”身上表现得更明显。
★开发人员让我看他的模型时，如果开口说“我先来给你讲讲”，我都会拦住，“如果还需要你先讲讲，说明你所想的没有体现在模型中”。
脓包二：遮羞
因为符号是“我”自创的，所以这个图的解释权归“我”所有。如果有其他同事质疑图上什么地方画得不对，“我”就有了充分的躲闪空间——“你理解错了，这个图形不是你以为的那个意思。你以为我画的是鹿，其实这是马，在我的规范里面，马就是鹿的意思，鹿就是马的意思”。
如果使用了标准的表示法，例如用UML画了一个状态机图，其他人就有得说了，“好像手册上不是这样说的”，“我看那个书上不是这样说的”，这不就尴尬了嘛。
自编图形未必是看起来十分简陋的白板草图，也有看起来比较精致的。例如，来自某项目的图1-11。
图1-11 自编图形示例
其实，抛弃标准符号和建模工具带来的便利，用绘图工具或幻灯片工具画出这样的图，所花费的时间往往还要更多。但是，有意思的是，有的人画这样的图，还以“敏捷”为理由。
注意，上面说的只是“看起来比较精致”，其实内容还是很粗陋的，仅仅是把一些动词、名词的罗列成一个个形状，各个形状之间的关系基本没有，读者可以把图1-11和图1-9、图1-10对比。
有心的读者可以观察近年来被吹捧为“革命性创造”的领域驱动设计的文章，看看其中所画的图，看看会不会发现上面所批评的情况，简单罗列，无一致性。然而，为了掩盖逻辑上的不足，这些图的作者会把力气下在“美工”方面，因此，伪创新的图有时看起来比科研风格的图更赏心悦目，对外行来说更有吸引力。
1.3.2.4 挑破乱七八糟图的脓包
我们甚至可以“抛开事实（具体领域知识）不谈”，仅从“一致性”这一点入手，就可以挑破这种自编“乱七八糟图”的脓包。
自编“乱七八糟图”的画图者，很可能并没有归纳过各种形状的定义，只是凭感觉随意使用，或者即使归纳了，也不会像标准语言这么严谨，所以，大概率会产生“不一致”的问题。
我们就以图1-11为例。
图1-11中，同样被称为“平台”的东西，有着不同的形状和颜色，如图1-12。
图1-12 图1-11的不一致示例1
我们再来看中间这些方框，如图1-13。
图1-13 图1-11的不一致示例2
先看图1-13的最顶上3个方框，它们形状一样，长度一样，但有的叫“层”，有的叫“模型”，有的叫“队列”，这些概念可不是一个级别的。
（可能的辩解）也许在颜色中暗示？
再来看方框里的命名。最上面4行的命名，基本上都是“名词+动词+名词”结构，例如“消费信贷+统一前置+层”、“额度+管控+模型”，最下面2行的方框，命名是“名词+动词”结构，例如“消费业务+管理”、“流程+控制”。
（可能的辩解）你没脑子吗，自己脑补一个尾巴不行吗，“……模型”、“……层”、“……功能”、“……队列”、“……AI赋能领域驱动设计革命性创新微服务功能模块组件分布式大数据数智化平台”。
还有，名称同样是“模型”，颜色也有多种……
读者可以尝试从“一致性”着手，看看身边的同事画的“乱七八糟图”有没有这方面的问题。
可能有人会问：难道用UML来画就没有这个问题吗？
有的，例如，建模人员故意往用例的圈圈里乱填东西，有的填名词，有的填动词，有的填形容词，但这是违反UML相关的规范或指南的，其他人可以看出问题，批评和纠正。刚才说的情况是没有规范或规范模糊，这两者是不一样的。
用法律类比：精确严谨的法律条文并不能保证没有人违法，但至少大家有共识，什么是违法，什么不是。而另一种情况则可能是，孪生兄弟张三和张四做了同样的事情，张三违法，张四不违法，理由？不知道。
《软件方法》各章合集
