漏斗图，领域驱动设计叒创新了？
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文章。
其他文章供参考：
《软件开发团队的脓包》里面的“废话迷”部分
