京东云开发者DDD妙文欣赏（1）

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更新）