（《京东云开发者DDD妙文欣赏》写于2024年1月，以系列文章方式发表，现合并成一篇文章）
京东云开发者原文链接：DDD落地实践-架构师眼中的餐厅>>，以下简称《餐厅》。
我们逐个逐个截图来赏析这篇文章。
图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
《软件方法》（http://www.umlchina.com/url/softmeth2024.html）第8章中的“8.2.4.2 关于DDD话语中的通用语言”，https://mp.weixin.qq.com/s/M4FsTzEt39CyeWN8I5mugg
（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的“用例流程图”。
图8 《餐厅》中的“用例图”
（01）
原文
用例图
赏析
揉一揉眼睛仔细看，确实写着“用例图”，不是领域驱动设计革命性创新的蛋蛋图。
那么，我们就按用例图的知识来赏析。
（02）
原文
理清谁在做什么
厨师→做菜
赏析
前面“统一语言”的脑图里说“做饭”，这里变成了“做菜”?我又揉一揉眼睛，后面紧跟着的“买菜”、“洗菜”和脑图中的一样，应该说的是一个东西。也许在强调统一语言的同时，又引入了量子力学加成吧。
**********
你猜，用例为啥有个“用（use）”字？
因为它说的并不是“A做B”，而是“A用X来做B”，或者“X向A提供了B的服务”。
这里的焦点是X，用例实质上是描述X作为一个整体对外提供哪些价值。
图9的左右两侧的图形表达都可以，但都要说清楚研究对象X，否则谈论用例是没有意义的。
图9 X的用例图
X可以是一个系统。此时，A就是X外面的另一个系统，A称为系统X的系统执行者（Actor），B称为系统X为系统执行者A提供的一个系统用例。这样的用例表达了X系统的需求。
*系统可以是人，也可以是非人智能系统或时间。当然，也可以把时间看作特殊的非人智能系统。
X也可以是一个组织。此时，A就是X外面的另一个组织，A称为组织X的业务执行者，B称为组织X为业务执行者A提供的一个业务用例。
*组织可以是正式组织，如企业、党政军单位、事业单位、社会团体，也可以是非正式组织，如人群、家庭、正式组织中的部门或团队。
**********
图8的“用例图”，研究对象X是什么？也就是说，是描述什么东西的用例？
这又回到了之前的赏析说到的“薛定谔的餐厅”，说“设计餐厅”，这个“餐厅”到底指什么？不说清楚这一点，这个“用例图”是没有意义的，除非画的是“领域驱动设计革命性创新的蛋蛋图”。
★如果“餐厅”指的是“餐饮企业”
“餐饮企业”是组织。图8中的三个小人“厨师”、“刀工”和“采购员”此时在“餐饮企业”内，可以看作“餐饮企业”的人肉零件，或者称为“餐饮企业”的业务工人。它们不是“餐饮企业”的Actor，“厨师→做菜”也不是“餐饮企业”的用例。
或者这样说，“餐饮企业”之所以存在，不是为了解决厨师的就业问题，让厨师有个地方做菜来获得薪水。老板巴不得不用请那么多厨师，搞一个外星黑科技烹调机来取代他们。顾客也并不在意菜是谁做的，只要味道好、干净、卫生、有营养、价格公道，没准外星黑科技烹调机的分子料理更受顾客欢迎。
“餐饮企业”之所以存在，是因为一些人群或机构需要用餐，但又不想自己完成购买食材、烹调、布置用餐场所、餐后清理的工作，于是由“餐饮企业”提供这个价值，这个价值可以称为“用餐”。
“餐饮企业”的用例图可能如图10。图中用“食客”替换了原文中的“顾客”。实际工作中还需要定位目标食客是哪种类型的食客，本文暂不考虑这个问题。
图10 “餐饮企业”的用例图
图10代表了“餐饮企业”的价值，非常稳定。时光倒流三百年，图10也是成立的，往后一百年，也应该是成立的……吧？
容易变的是用例的实现，即“餐饮企业”的业务流程。图11是某餐饮企业“***餐厅”于2018年的业务流程片段。可以看到，“食客扫码点餐”等场景尚未出现在当时的业务流程中。
图11 用序列图表达某餐饮企业“***餐厅”于2018年的业务流程片段
“厨师”作为业务工人出现在图11中，但和“取号系统”、“餐馆管理信息系统”等没有交互——虽然“餐馆管理信息系统”有一条虚线指向“厨师”。
也就是说，无论是以“餐饮企业”为研究对象，还是以“取号系统”、“餐馆管理信息系统”为研究对象，“厨师”都不是Actor。当然，“厨师→做菜”也不是用例。
图12 厨师不是Actor
★什么情况下，厨师会是Actor？
一种情况是，研究对象是一个组织，厨师作为组织外的一个人群和该组织交互。
例如，以“餐饮协会技能评定中心”为研究对象，“厨师→考厨师证”就是用例。
图13 厨师作为执行者，例1
思考题：
多年前，电子支付还没有普及。有一家较大的餐饮企业，发薪水都是发现金。假设我们去观察，可能会看到一名厨师到财务部去领薪水。请问“厨师→领薪水”是“财务部”的用例吗？
另一种情况是，研究对象是一个系统，厨师作为系统外的一个系统和该系统交互。
例如，以封装了一些烹调智慧的“智能烹调机”为研究对象，“厨师→做菜”就是用例。
图14 厨师作为执行者，例2
思考题：
假设研究对象是普通的炒锅，请问“厨师→做菜”是炒锅的用例吗？
★如果“餐厅”指的是“虚拟餐厅”
例如做一款游戏，把现实中的一切人、物、事都搬进去。
以这样的系统为研究对象，Actor就是游戏玩家。
如果这个“虚拟餐厅”厉害到黑客帝国中Matrix的地步，那Actor就只有时间了。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
