[答疑]漏斗图,领域驱动设计叒创新了?

2024-01-08 09:29:21

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的建模示范视频-全程字幕

文章来源:https://blog.csdn.net/rolt/article/details/135448599
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。