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 原文的“用例流程图”
下一篇文章，我们再来赏析这张“用例流程图”。
UMLChina公众号精选（20240108更新）
