是有代表性的。这说明了为什么 [Industry] 域模型确实应该将公司定义为黑盒子中心的演员。同一个行业中的公司倾向于支持带有其外部演员的同一套业务交互。此外，域模型排除了公司的特定业务处理，这是因为在同一行业中的公司之间它们会有相当大的变化。
域层次严格集中在从外部演员的角度看到的业务交互。对此我们必须注意，不要将用于完成交互的实现机制包括进来。这些细节属于下一个抽象层次。因此，在本例中，我们只为浏览、选择、购买和支付建模。我们不为如何完成这些交互（通过电话、美国邮政、电子邮件、Web 应用程序、亲自前往、支票、信用卡或现金）建模。
业务处理抽象层次
下一个抽象层次为公司的业务处理建模，以实现在域层次捕获的交互。系统层次“内部缩放”公司的黑盒子，并标识为完成业务交易而协作的所有员工和系统。在这个层次，要开发的系统作为黑盒子中心的演员。
应用了系统层次的范围规则，在线定单系统就作为黑盒子中心的演员。客户和员工作为外部演员。系统层次是从客户和员工的角度来建模的。客户在线执行购买。支付是通过信用卡完成的。通过将物品运送到客户的收货地址履行定单。出货通知是由电子邮件发送的。
动态视图
动态视图重演了域层次购买交易，这次公开了零售商的内部业务处理。图 4 汇总了业务处理环境，并包含了关于系统及其演员之间的交互的简单使用案例描述。
静态视图
这个层次的静态视图对类模型做了改进，以捕获在业务处理层次使用案例中出现的对象。换句话说，“为了在线创建一个定单并履行该定单，客户和雇员需要理解哪些对象？”图 5 展示了业务处理层次静态视图的类关系图。我们修改域类模型以捕获在这个抽象层次上的角度。Person、Account 和 Company 抽象保持不变，Catalog 和 Product 也一样。但是，用 Order 替换了来自域模型的抽象 Purchase 事件。
Order 包括 LineItem，它与 Catalog 中的 Product 相关联。因为这个层次为公司的内部业务处理建模，所以我们需要获得现有的库存（最小库存单元 (SKU) 的一个属性，它表示在一个特定位置的物品的库存）。我们也为客户的 UserAccount 建模，它提供对在线系统的访问。Payment 是通过使用 CreditCardAccount 来完成的。Location 代表美国的一个地理位置，它作为账单邮寄地址，同时也作为 Order 的收货地址。Shipment 包含 Shipment 中包括的 Item。
我们在系统抽象层次创造方法来简化业务处理，因此该层次通常需要很多创造力。为此，通常使用业务处理层次上的若干不同形式来实现单个域层次交易。举例来说，一次购买可以通过在线、电话、邮件、传真一个定单表格或者亲自到零售店来完成。对于每一种形式，都需要在业务处理层次为其建模。请注意，尽管对零售商来说 Credit Authorizer 是一个外部演员，但是它还是在这个层次引入，这是因为只需要它实现在该层次首次出现的业务处理。
最后，请注意该系统是技术独立的。我们的在线购买系统可以用任何 Web 技术实现。在系统黑盒子内选择技术是一个体系结构决策。
逻辑抽象层次
逻辑层在系统黑盒子内缩放，从而公开高级别的系统设计。架构师选择技术并定义高级系统结构。在我们的简单示例中，系统是由承载表示层、业务层和数据访问层的 Microsoft IIS/Microsoft ASP.NET 服务器和承载持久性数据的 Microsoft SQL Server 数据库服务器组成的。
动态视图
文章来源于领测软件测试网 https://www.ltesting.net/
