图图 5. 关于从零售商处购买物品的业务处理层次静态视图关于从零售商处购买物品的业务处理层次静态视图
客户是 Person 的实例。客户和零售商之间的关系被具体化为 Account。所有的
Purchase 都与客户的 Account 相关。Purchase 与每个被购买的 Item 相关。每
个 Item 都与特定的 Product 相关,这里 Product 遵循元类模式。Product 的实
例实际上本身就是类。将其他 Product 添加到 Catalog 完全是一个数据驱动过
程,而且不会对类模型产生影响,因此将 Product 建模为一个元类会使我们的模
型更加灵活。围绕这些类,每个 Payment 都与其 Purchase 相关。
如您可能看到的,这个层次的模型对大多数零售商(无论类型为在线或传统,大
型或小型)来说是有代表性的。这说明了为什么 [Industry] 域模型确实应该将公
司定义为黑盒子中心的演员。同一个行业中的公司倾向于支持带有其外部演员的
同一套业务交互。此外,域模型排除了公司的特定业务处理,这是因为在同一行
业中的公司之间它们会有相当大的变化。
域层次严格集中在从外部演员的角度看到的业务交互。对此我们必须注意,不要
将用于完成交互的实现机制包括进来。这些细节属于下一个抽象层次。因此,在
本例中,我们只为浏览、选择、购买和支付建模。我们不为如何完成这些交互
(通过电话、美国邮政、电子邮件、Web 应用程序、亲自前往、支票、信用卡
或现金)建模。
业务处理抽象层次业务处理抽象层次
下一个抽象层次为公司的业务处理建模,以实现在域层次捕获的交互。系统层
次“内部缩放”公司的黑盒子,并标识为完成业务交易而协作的所有员工和系统。
在这个层次,要开发的系统作为黑盒子中心的演员。
应用了系统层次的范围规则,在线定单系统就作为黑盒子中心的演员。客户和员
工作为外部演员。系统层次是从客户和员工的角度来建模的。客户在线执行购
买。支付是通过信用卡完成的。通过将物品运送到客户的收货地址履行定单。出
货通知是由电子邮件发送的。
动态视图动态视图
动态视图重演了域层次购买交易,这次公开了零售商的内部业务处理。图图 4 汇
总了业务处理环境,并包含了关于系统及其演员之间的交互的简单使用案例描
述。
静态视图静态视图
这个层次的静态视图对类模型做了改进,以捕获在业务处理层次使用案例中出现
的对象。换句话说,“为了在线创建一个定单并履行该定单,客户和雇员需要理
解哪些对象?”图图 5 展示了业务处理层次静态视图的类关系图。我们修改域类模
型以捕获在这个抽象层次上的角度。Person、Account 和 Company 抽象保持不
变,Catalog 和 Product 也一样。但是,用 Order 替换了来自域模型的抽象
Purchase 事件。
Order 包括 LineItem,它与 Catalog 中的 Product 相关联。因为这个层次为公司
的内部业务处理建模,所以我们需要获得现有的库存(最小库存单元 (SKU) 的
一个属性,它表示在一个特定位置的物品的库存)。我们也为客户的