合适的责任 ·业务序列图-202606更新《软件方法》第4章

DDD领域驱动设计批评文集

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

《软件方法》各章合集

4.1 建模步骤A-4 组织的现状流程

4.1.2 业务序列图

4.1.2.5 合适的责任

在业务序列图上，分配给系统的责任必须是该系统有能力承担的。

例如，我们平时描述业务流程时可能会说“工作人员用Word做标书”，如果照搬说话的内容，不假思索画出图4-19，责任分配是不正确的。

图4-19 不恰当的责任分配

Word无法承担“做标书”的责任。这个软件系统里的代码可能有“文档”、“段落”、“字体”等概念，但不会有“标书”的概念。“标书”有可能是软件运行时某个“文档”实例的“标题”属性值。

“标书”的概念可能会封装在工作人员的大脑中，改为图4-20更合理。

图4-20 恰当的责任分配

“标书”可以作为文档的实例出现在消息的实参（Argument）位置，如图4-21：

图4-21 “标书”出现在实参位置

EA上的属性框设置如图4-22，①处的“文档”是类型，②处的“当前文档”是形参，③处的“标书”是实参。

图4-22 EA的属性设置界面

如果③里面有内容，消息上显示的就是“制作文档（标书）”；

如果③里面没有内容，缺省显示①，即“制作文档（文档）”；

如果③里面没有内容，且该序列图被设置为显示参数名而不是类型，那就显示②，即“制作文档（当前文档）”

★严格来说，“标书”不是“文档”实例，只是某个“文档”实例的某个属性（例如“名称”）的值。

序列图描述的是组织流程或系统运行的“快照”，上面的参数应该是实参。但是，很多时候，序列图上的参数显示为形参甚至类型，也是可以理解的。

例如，我们画完消息后，把它映射到实例的类元的一个已有操作，不再单独给消息和参数命名。此时，类元中操作的定义是怎样的，序列图上的消息就是怎样的。如图4-23所示，序列图上指向“微信”的消息的内容就是照搬类图上的“微信”类的操作。

图4-23 序列图上的消息对应类元的操作，右侧是EA工具的属性框

有的时候，画某条消息就是为了推导操作以及背后的类元。例如，先有一个待分配的责任“发消息”，然后思考这个消息应该由哪个类元（在业务建模工作流就是业务工人和业务实体）负责。如果思考的结果认为，需要添加新的操作甚至需要先添加新的类元，则先添加，然后把消息映射到该操作。

以上讨论的仅是消息的参数展示，这个可以灵活变换，但责任本身是不能随意修改的。如图4-24，指向微信的消息为“发会议通知”是不行的，其他几个可以。

图4-24 指向微信的合适消息