DDD领域驱动设计批评文集

做强化自测题获得“软件方法建模师”称号

《软件方法》各章合集

---

丁绍恒 2024-5-8 16:17

（补注：上图摘自https://mp.weixin.qq.com/s/QhAhSdET5psZQEEW6f9KoA）

1、您提到“【警戒条件】是一个【表达式】，例如a+b>c，其中的【变量】是【类】的【属性】”；那么这些【变量】a、b、c，究竟是哪个【类】的【属性】？是本状态机所描述的类么？（如果不是，为何可以省略类名、只写属性名？不会混淆命名空间么？）

比如，在图31中，【变量】“婚龄上限”（批注1.1）是哪个【类】的【属性】——既非“人”【类】的【属性】，也非“性别”【类】的【属性】？（在图30中，“性别”【类】只有“法定婚龄”【属性】（批注1.2），没有“婚龄上限”【属性】。）

而“当前日期”（批注1.3）是不是【变量】？如果是，又是哪个【类】的【属性】？

2、您提到“【警戒条件】是一个【表达式】，例如a+b>c，其中的【变量】是【类】的【属性】”；【警戒条件】的【表达式】中，【变量】必须是【属性】么？

如果是，在图31中，“已达婚龄&&无病”这个【表达式】（批注2.1）中，谁是【变量】？分别是哪个【类】的【属性】？

如果不是，【变量】也可以是【状态】吧？但“无病”这个【状态】在本机中没有出现？——本机中出现的【状态】是“无禁婚疾病”（批注2.2）。

有没有关于【表达式】的BNF表达式？

3、在图31中，“配偶.丧偶”（批注3）是行为表达式吧？在图30中，扮演“配偶”这个【角色】的【类型】是“人”【类】，但“人”这个【类】中并没有一个名为“丧偶”的【操作】？其他行为表达式也没有在类图中找到对应的表达，是不需要表达么？

4、在图31中，“配偶数”（批注4）是谁的【属性】？

5、我想我的这些困惑大致是来自一种预设：行为模型依赖结构模型（行为的主语和宾语全部都应该在结构中有所反映？），因而状态机图中出现的所有结构事物（甚至包括一些行为事物），都应该能在类图中找到对应的表达？

如果这个预设正确，那么理想的建模工具应该能“理解”这种对应关系，从而在书写各种表达式（状态不变式、条件表达式、行为表达式……）的时候，可以像代码编辑器一样主动地提示或补充上下文？而非麻木地提供“自由度”？

然而，EA似乎并没有这么做？是因为我不熟悉EA的操作，还是错误地理解了“建模”活动本身的领域模型呢？

6、

您为何在传授“建模”方法的时候，宁可采取自然语言，而非建模语言呢？在哪里可以找到“建模”本身的完整模型呢？

UMLChina潘加宇

先要赞一个，看得非常仔细。

1、

状态机是类的状态机，属性指状态机所描述的类（即左上角的“人”）的属性，包括直接和间接的属性，间接的例如“性别.法定婚龄”。

图中标注1.1处的“婚龄上限”错误，应改为和属性名称一致的“法定婚龄”。

标注1.3处的“当前日期”即当前时钟，相当于编码中的now或getdate，不属于哪个类的属性。

另外，严格来说，“性别”的“法定婚龄”属性不能直接访问，在实现时，“性别.法定婚龄”可能是一个getter或property。

在警戒条件的布尔表达式比较复杂时，甚至有可能把式子封装进一个操作，如“年龄达标”，此时出现在警戒条件处的可能就是“年龄达标”。

2、

标注2.1处的“已达婚龄”和“无病”是“活”状态的另外两个分区的当前状态。

“无病”应改为“无禁婚疾病”，以和另外两个分区的状态名称一致。

警戒条件的布尔表达式目前没有标准语法，可以用OCL，也可以用熟悉的编程语言，语法都差不多。参见《状态机迁移的警戒条件怎么写，有标准格式吗》。

至于BNF怎么表达，搜关键词“BNF Grammar Expression”之类应该可以搜到很多，或者直接搜你熟悉的编程语言，例如“Java BNF”，在得到的文档内部再搜expression。

3、

标注3处的“配偶.丧偶”是action，这个action是向关联的“配偶”发送“丧偶”的消息。

因为“配偶”也是“人”，所以“人”应存在“丧偶”操作，不过所有操作都没画，包括“患病”、“治愈”、“结婚”……。

另外，此处还需要进一步修正。

配偶可能为多个，因此“配偶.丧偶”严格来说是不对的，应改为“配偶s->forAll(配偶 | 配偶.丧偶()) ”（OCL），也可以用某种编程语言表达，或者把这个内容封装进一个操作“所有配偶丧偶”。

4、

标注4处的“配偶数”不严谨，可以改为“配偶s.count”。同时，把关联的角色名改为“配偶s”，表示可能有多个配偶。

修正过的图如下：

5、

如果建模工具足够智能，应该不允许我在上面几个地方出现不严谨的表达，至少给出提醒。

例如，本来类图中是“婚龄上限”，后来认为“法定婚龄”更好，于是改了类图，但蔓延到状态机图的“婚龄上限”被忽略了。

自由度是要有的，因为有的时候甚至在没有类的信息的时候直接画状态机图、序列图，但建模工具应该具备需要严格的时候能严格起来的能力。

可惜，建模工具在这方面目前还很弱，像EA有Model Validation（菜单中搜索Validate），但仅能检查简单的错误。如下图，左侧可以检查出来，右侧检查不出来。

更细致的内容，特别是涉及到方法学的，几乎是没有的。

特别是20年来，在“敏捷”的风气影响下，很多厂商没有能够往深度探索，而是跟随“敏捷”的“染色”，陷入重复包装、造词的伪创新。

6、

首先要澄清一个误解：“简洁”不等于“容易学”。

像下面这些够“简洁”，但并不“容易学”。

线性方程组有解<->系数矩阵与增广矩阵有相同的秩

方程存在根式解<->方程的群存在因子全为素数的子群系

伪创新经常混淆两者，嚷嚷“大道至简”，其实背后意思是“不动脑子也能学会的才是好方法”。

当然，伪创新不会直接这么说，而是把很粗浅的内容换上充满玄学的名字，对外宣称这个内容很难——此处很关键！

开发人员一开始以为很难很深奥，上手一学，发现其实不难！可以说是：投资少，见效快，产量高，门槛低，仪式感十足。开发人员立刻有捡到了便宜的感觉，心中豪气顿生——不愧是我！别整三岁的，有能耐你整四岁的！

有心的读者可以看看和领域驱动设计相关的文章，看看有没有这样的模式：作者在文章一开始感叹“领域驱动设计好难！”，然后再往下看内容，哈，一点复杂的逻辑思考都没有。

而真正能解决难题的知识，有可能看起来很难，学起来确实也很难。

即使有的时候它用简洁的方式表达，让人误解容易学，结果一学还是很难，于是从入门到放弃，投入伪创新的怀抱。

此处可参见《漫画版《软件方法》、奶头乐和高数买菜》。

**********

关于元模型，UML规范里就有，如下图。不过仅限于表示法，方法学方面是没有的（《软件方法》第9章尝试提供方法学的元模型）。

20年前的《非程序员》杂志也可以参考，下载地址:

umlchina.com/xprogrammer/index1.html