DDD领域驱动设计批评文集

做强化自测题获得“软件方法建模师”称号

《软件方法》各章合集

---

albert 2024-1-1 21:11

这篇文章说用DDD重构****，演示了一种漏斗图，请教潘老师，这个图是DDD提出来的吗，您怎么评价？

UMLChina潘加宇

我看了你说的文章。

（1）作者画的不是“漏斗图”。

漏斗图（Funnel Chart）是描述某个变量的值随着流程（例如销售、招聘等）的进行逐渐减少的情况，例如:

图1

也可以横过来，例如：

图2

漏斗图在商业中应用得比较多。下图摘自20多年前的营销领域书籍：

图3 摘自：《八种武器No.1:大客户销售策略（最新修订版）》，付遥 著，2002年1月出版。

画漏斗图的目的是讨论：到底什么环节出了问题，为什么会被过滤掉这么多？

例如，图1这张漏斗图，发出去5万多，购买的只有500多（不知道发的啥，如果是Email，这个转化率似乎已经很棒了？）。

而你说的文章中的图，作者的目的是这个吗？难道作者觉得最终通过重重检查的房间个数太少，要找到其中的病根？

★不得不说，问题所给图中的右下角那一连串的“失败”，刷工作量刷得真爽。

（2）作者可能想画的是Nassi-Shneiderman图（Nassi-Shneiderman Chart）。

Nassi-Shneiderman图，也称N-S图或盒图。它由Ben Shneiderman和Isaac Nassi于1973年提出（https://www.cs.umd.edu/hcil/members/bshneiderman/nsd/1973.pdf）。发明者的初衷是：既然程序中要避免使用Goto语句，那么表示法也应该避免使用流程图中带箭头的线条。

N-S图和流程图的对应如下：

图4 摘自Visual Programming, Shu, N. C. , 1988

N-S图的内容，国内的软件工程教材一般都会有，目前也还是软考的知识点。

当然，文章作者并没有在文章里说这是作者的创新或DDD的创新，应该只是不了解这些知识。

**********

DDD圈子的同学，如果想“创新”，可以先稍微认真学习一下前人的知识，然后把“盒图”创新为“领域驱动设计●思辨匣●画布”。

注意仪式感！

不要说“逻辑”，说“思辨”，不要说“盒”，要说“匣”，不要说“图”，要说“画布”，而且一定要强调手绘，糊墙！

我多次批评过，DDD圈子有封闭引用的特点。例如，问题所提文章末尾列出5篇参考文献，均在DDD圈子内部。

所以，可以考虑圈子中派出一个人，包装或创新一个“领域驱动设计●思辨匣●画布”，以后就可以作为圈子内引用的根源。

**********

以下是本问题的扩展：

（3）N-S图的进一步知识

一张图由若干顶点和若干边组成，显式的表达是连接型。

例如，下面几张图是等价的：

图5 连接型表示

如果硬要说“怎么一样呢，一个长一个短，一个上一个下”，要关注这个的话，需要给边（或顶点）添加属性来表达。

流程图可以看作以连接型的方式表达的图。

如果引入某种隐含的约定，就可以让边退化，变成邻接型或包含型。

邻接型如：

图6 邻接型表示

图6可能就隐含了约定：邻接处存在从左到右或从上到下的有向边。

这时，A、B的相对位置可就不能乱放了，也没法再给边添加属性（名称、权值等）。

包含型，相当于把图7改成图8：

图7 连接型表示

图8 包含型表示

同样，图8中，A和B之间的关系是隐含的，B的位置和大小受到严格限制。

★注意，图5-图8只是普通的图形演示，和具体的表示法如UML无关。

N-S图可以看作边退化之后的流程图。

关于连接、邻接、包含这几种表示方式的优缺点和适用性，应该有过很多研究，而且不只是计算机和软件行业。毕竟各行各业都需要图形表示法，这是一个普遍的问题。但这方面更详细的内容我也没有研究过，感兴趣的读者只好自己查询了。

就我了解稍多一点的软件建模工具EA来说吧。EA除了支持UML/SysML，还支持各种各样的表示法，包括已经可以被取代的流程图、E-R图、数据流图等，但这些表示法都是“连接型为主+包含型为辅”，没有像N-S图这样把连接型干掉的。

例如，UML的类图中，类和类之间的关系表达是连接型的，类和属性、操作之间关系的表达则是包含型的，属性和操作画在类框里。

UML的类图表示法主要来自Rumbaugh的OMT。Rumbaugh曾在他的书中比较了OMT的类图和E-R图，如图9。可以看出，图9中的E-R图全部是连接型的表示。

图9 摘自Object-Oriented Modeling and Design, James R. Rumbaugh等，1991

我之前也写过一篇：

[答疑]把聚合关系画成方框套方框是不是更好

**********

最后说一句，像问题所提到文章中的逻辑，更合适画的图可能是状态机图。

（4）DDD文章的老问题

就拿问题给出的这张被称为“漏斗图”的图来说，如果系统的复杂逻辑就是这样沿着一根轴几十个条件判断下来，那这个系统还真不算复杂。

复杂的难道不是“分区参数正确”、“用户权限正确”等这几十个条件的真假是怎样得出来的吗？结果在文章里看不到，大量的内容讨论分层、六边形架构。

啥？这些规则都已经由张三在别的地方封装好，作者这边只需要调用就行了？如果是这样，那应该让张三来写DDD美文才对呀！

这也是各种各样的领域驱动设计文章的一个普遍的致命问题，说来说去一大堆，却没有能力把最难的规则显式建模。当然，如果文章作者有能力做这个，他压根就不会相信这些伪创新，自然也就不会有各种奇奇怪怪的DDD文章。

其他文章供参考：

《软件开发团队的脓包》里面的“废话迷”部分

[答疑]是不是互联网更适合用DDD

**********

逆境求生：《软件方法》思考利器助你凛冬“创业”

[EA-029/石油钻井管理平台]35套UML/SysML+EA/StarUML的建模示范视频-全程字幕