DDD领域驱动设计批评文集
做强化自测题获得“软件方法建模师”称号
《软件方法》各章合集
2.4 建模步骤A-2 定位系统的愿景
2.4.1 愿景的定义
如果有一个系统规格S，S的开发组织是O1，开发组织负责人是P1，S的目标组织是O2，目标组织负责人是P2，那么系统规格S的愿景定义为：
在P2期望的O2的改进期望集合中，P1认为S能满足且当前排序最高的那一项。
把这些概念添加到之前已有的类图上，得到类图如图2-30：
图2-30 添加了愿景定义相关概念之后的类图
“系统规格”和“改进期望”之间的关联不是冗余的，因为从目标组织的若干改进期望中挑选哪一个作为愿景，取决于建模人员所揣摩的开发组织负责人（P1）的选择。也就是说，从“系统规格”出发，沿着图2-31所示的路径，无法推导出愿景。
图2-31 按照这条路径无法推导出愿景
本小节开头的文字，用对象图表示如图2-32：
图2-32 本小节开头的文字的对象图
我们可以把S、O1、O2、P1、P2替换成更接近真实的内容，以帮助理解：
S（系统规格）：四两拨千斤系统
O1（开发组织）：很快啊供应链科技有限公司
P1（开发组织负责人）：很快啊供应链科技有限公司总经理 马宝国
O2（目标组织）：京西集团华东一号转运中心
P2（目标组织负责人）：京西集团运营总监 刘劲西
刘劲西刘总（P2）对京西集团华东一号转运中心（O2）有如下改进期望：
*提升单位面积的货物存储量（排序=1）
*降低大促期间包裹的分拣错误率（排序=2）
*降低仓库电费支出（排序=3）
马宝国马总（P1）认为“降低大促期间包裹的分拣错误率”是四两拨千斤系统（S）的愿景。
对象图如图2-33：
图2-33 供应链领域的对象图
严格来说，“马宝国”、“刘劲西”并非“系统”的“名称”值，而是“容器”的“名称”值，但如[2.1.3 系统和系统规格]所说，我们在模型中省略了“容器”，在需要一个名称的时候，直接认为是“系统”的“名称”。
可以在“系统规格”上加一个约束，确保愿景来自目标组织（的指标集合）的改进期望集合。添加了约束后的类图如图2-34：
图2-34加上约束后的愿景相关概念类图
OCL支持把aSet->collect(name)简写为aSet.name，图2-34中约束也可以改为：目标组织.指标s.改进期望->includes(愿景)。
