本文主要是介绍京东云开发者DDD妙文欣赏(2)报菜名和化繁为简的创新,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
DDD领域驱动设计批评文集
做强化自测题获得“软件方法建模师”称号
《软件方法》各章合集
京东云开发者原文链接:DDD落地实践-架构师眼中的餐厅>>,以下简称《餐厅》。
我截图时,阅读量有6044,在同类文章中已经算是热文了。
我们逐个逐个截图来赏析这篇文章。
图1 截图第1部分
(01)
原文
领域驱动
赏析
没有说“领域驱动设计”,但结合文章题目中的“DDD”,这里说的应该就是“领域驱动设计”里的“领域驱动”。
(2)
原文
以领域驱动为核心思想,结合架构设计与功能设计方法论。
赏析
既然需要“结合”,意味着“领域驱动”只是“核心思想”,不包括“架构设计”和“功能设计”方法论。
(按《软件方法》,此处的“架构设计”应该对应于分析和设计,“功能设计”(模糊用语)应该对应于需求。)
妙就妙在:进可攻,退可守。
文章题目虽然叫做“DDD落地……”,但里面画了不少UML图——虽然我水平有限,看得迷迷糊糊,但应该看得出来是UML图,或者说,作者认为自己在画UML图。这些图我在后文会一一赏析。
如果这些UML图画得好,那就可以说UML体现了“领域驱动”的核心思想——UML是领域驱动设计的一部分——凡是有用的,都是敏捷的,也都是领域驱动设计的。
如果这些UML图画得不好,那就可以说UML不能体现“领域驱动”的核心思想——UML不是领域驱动设计的一部分。
另外,“功能设计方法论”可以改为“业务用户领域需求功能模块设计方法论”,这样更能体现领域驱动设计的精髓。
(03)
原文
我要设计一个餐厅
内容偏重于落地
不针对餐厅的实现细节
赏析
设计一个餐厅,既要“内容偏重于落地”,又要“不针对餐厅的实现细节”,这怎么做到呢?
莫非这里的“餐厅”的含义灵活多变?意思有时是“餐饮领域的智能系统”,如智能炒菜机、餐饮MIS,有时是“建筑空间”,有时是“餐饮企业”?
后文的各种图,也体现了这一点。
(04)
原文
全程干货、耐心读完、必有收获。
赏析
嗯,我们耐心读一读。
(05)
原文
领域分析
领域设计
让我们抛开技术人员的本能技术视角、站在纯业务视角来分析领域问题。
赏析
一开始说的是“领域分析”,接下来说的却是“领域设计”,这两个的区别是什么?是《软件方法》常说的C-分析和D-设计的区别,还是领域驱动设计的又一个创新?看来今年的DDD演讲又有题目了。
但接下来㕛有转折:“领域设计”是“站在纯业务视角来分析领域问题”,不是“设计”了,又变回了“分析”。
“本能技术视角”提醒我们,还有“非本能技术视角”,“纯业务视角”提醒我们,还有“非纯业务视角”。
(06)
原文
领域设计的核心是分而治之。
赏析
这一句发人深省。
要是不学习“领域设计”,软件开发人员还不知道要“分而治之”呢。
(07)
原文
从宏观流程去分析,可以帮我们迅速找到重要的区域。
赏析
厉害!从宏观流程就可以迅速找到。
说的是“区域”,不是“领域”。也许指的是餐厅建筑空间的物理区域(area),而不是说领域(domain)?
(08)
原文
会得到几个明确的行为区域,我将餐厅划分为“菜品域”,“订单域”,“厨房域”,“用餐域”,这是业务级别的领域划分,后续应该针对每个区域单独分析。
赏析
行为区域——这个“域”似乎指的是area?
菜品域——这个“域”似乎指的是domain?
但接下来又提到“领域划分”,再接下来,又说“针对每个区域”。
“业务级别的领域划分”,那有没有“技术级别的领域划分”?
领域驱动设计就是这么玄妙!
我揣摩其中的玄机,是不是这样:
把顾客就餐的流程分为四段,也就是四个“行为区域”,而这四个“行为区域”就映射了四个领域:“菜品域”,“订单域”,“厨房域”,“用餐域”,像下面这样?
图2 映射关系
先不说按照流程顺序来划分领域是否合适,就算一定要这样划分,是不是应该把流程画得细一点?从这么四步,还真看不出怎么就刚好推导得到这四个领域?
哎,往下翻,还真有一张:
图3 原文的“用例流程图”
为了不打乱逐个截图赏析的顺序,我们等到出现图3的地方再正式赏析这张“用例流程图”。
**********
图4 原文的“统一语言”脑图
(01)
原文
统一语言
赏析
把一些词汇的简单罗列称为“语言”,这是领域驱动设计的一项革命性创新。
关于Ubiquitous Language(通用语言、统一语言),我制作过的视频和写过的文章:
DDD领域驱动设计伪创新 之 通用语言 01,https://b23.tv/RE2hyDc
DDD领域驱动设计伪创新 之 通用语言 02,https://b23.tv/MymL2Kt
《软件方法》第8章中的“8.2.4.2 关于DDD话语中的通用语言”,https://mp.weixin.qq.com/s/BNKdD58_miynSQkfyWLVWA
(02)
原文
概念定义
赏析
概念定义没找到,只看到词汇的简单罗列。
(03)
赏析
铲子、锅、菜刀是厨具的一种,这是泛化关系,即集合的包含。厨具的对象集合包含铲子的对象集合。
“做饭”这里就不一样了。1次做饭由1次买菜、n次洗菜,n次切菜、n次烹饪……组成,这是关联关系,即个体的组装。
不同的关系,却用同样的方式罗列,这也许是领域驱动设计化繁为简的创新吧。
文字中写“做饭是制作菜品的行为,包括做蛋炒饭……”,但“做饭”下面又有“买菜”等等,此处可能引进了量子力学,和DDD一起使用更是如虎添翼。
“包括”可能是“例如”?一个是概念和子概念,一个是概念和实例。
名词部分几乎都是分类的罗列,其实我更想看到菜品-食材之间有什么关系。例如,该餐厅一例京酱肉丝需要什么材料,分别是多少量。可惜没有。也许需要打通关才能看到吧。
(04)
赏析
京酱肉丝、烤鸭等也要提炼为领域概念?这已经是菜品的实例了,或者说是菜品的“名称”属性的值。
嗯,学到了DDD的优点。投资少,见效快,产量高。
下次可以多提炼一点,把图填满:蒸羊羔、蒸熊掌、蒸鹿尾儿、烧花鸭、烧雏鸡、烧子鹅……筒子鸡,一碗米饭我够了。
图5 相声《报菜名》,马志明、黄族民
以前我画过的一张餐饮领域的类图,供参考:
图6 餐饮领域类图(潘加宇)
**********
“简单罗列”这个词后文还会不断出现。
图3的“用例流程图”,也是一种简单罗列。
流程图最早出现于1921年,由Gilbreth等人用于机械工程领域。后来,Goldstine和von Neumann将其引入计算机领域用于表达程序逻辑。现在UML中叫“活动图”。
流程图虽然叫“流程图”,但它的价值却在于其中的分支、循环等控制逻辑,如果顺着“流”下来就完了,von Neumann他们当初继续用文本表达不好吗?
以前我画过的一张活动图(流程图),供参考:
图7 “**助手”系统的“******”用例的活动图(潘加宇)
不过,要像图7这样画,难度陡升。
领域驱动设计大大降低了门槛,画到图3的“用例流程图”就可以称为DDD架构师了。这也是领域驱动设计受到广大开发人员欢迎的原因。
以上只是针对“简单罗列”的表述,后文还会正式赏析图3的“用例流程图”。
待续……
这篇关于京东云开发者DDD妙文欣赏(2)报菜名和化繁为简的创新的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!