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的“用例流程图”。
待续……
