动态视图
逻辑层上的动态视图跟踪通过系统主要组件的消息流。如示例所示，在提交 ConfirmOrder Web 表单的时候，图 6 跟踪这一消息流。
图 6. 从零售商处在线购买物品的逻辑层次动态视图
静态视图
这个层次的静态视图也将我们的视角切换到系统内部。尽管业务处理层次为出现在业务处理中的真实抽象建立了模型，这个层次将抽象建模为其在系统中所要被表示的那样。在实际的系统中，架构师会为每个软件层（表示层、业务层和数据访问层）设计类。为了保持本文的简洁，图 7 只展示了业务层的静态设计，以便说明系统层抽象是如何针对设计进行改进的。
图 7. 从零售商处在线购买物品的逻辑层次静态视图
架构师对系统层类进行改进以设计业务层接口。
因为系统中的所有账户和客户都是零售商的，所以创建一个单一的 Company 实例并使其与所有账户相关联是不切实际的，因此该层次中省略了 Company。我们只是存储 Payment 所带的信用卡号和账单邮寄地址，并非为每个 CreditCardAccount 创建一个单独的实例。此外，对系统来说，为每个出售的 Item 创建一个实例是不切实际的，因此从模型中删除了 Item，并改为由模型跟踪 LineItem 中订购的物品数量以及在新 ShippedItems 类中附带的物品数量。
架构师还定义业务层公开的服务间隔。对于本示例，业务层为 Account、UserAccount、Order、Shipment 和 Catalog 导出了 Create、Read、Update 和 Delete (CRUD) 服务。椭圆形指出了 CRUD 间隔。
请注意，即使本层次的类不是业务处理类的合适超集，架构师也可以通过直接改进业务处理类、将视角由系统外部更改为系统内部来实现这个设计。
物理抽象层次
物理抽象层次捕获系统实现的结构。系统作为一个节点的网络实现，每个节点都配置有硬件和软件。逻辑视图中的三个软件层（表示层、业务层和数据层）是以代码形式被物理实现，并部署到这些节点上。逻辑视图中的持久类物理存储在 SQL Server 数据库的关系表中。
动态视图
动态视图跟踪经过物理配置节点的消息流。ConfirmOrder HTTP post 从客户的浏览器通过 Internet 通过零售商的防火墙流动到 Web 服务器，在那里 Microsoft Windows 将其转发到 IIS，IIS 又将其传递到 Microsoft ASP.NET，然后 ASP.NET 调度 ConfirmOrder.aspx。幸运的是，现代开发工具将我们与多数物理网络隔离开来。但是，架构师需要了解物理层以避免网络瓶颈和安全暴露。
静态视图
静态视图（图 8）将逻辑视图中的持久类改进为其物理表示形式。在我们的零售示例中，业务层类存储在下列 SQL Server 表中。
图 8. 从零售商处在线购买物品的物理层次静态视图
映射到关系表和属性的类作为列实现。一对一关系和一对多关系使用一个外键来实现。开放式并发通过给每个被“凝结”的父类分配一个 datetime 字段来实现。
在设计逻辑层次时，架构师主要集中关注于实现系统功能。在确信包含了系统功能之后，架构师就能够专注于在物理层次优化实现。
通过迭代发展层次
建立了这个框架后，架构师通过几次迭代对解决方案加以发展。每次迭代都合并额外的功能 — 发票、待交定单、亲自订购、电话订购等等。在每种情况下，架构师都更新适当的抽象层次，然后将这些更新改进到物理实现层。
重访抽象层次核心原则
让我们对照核心抽象层次原则来测试我们的示例。
·这些层次的数量和范围是定义完善的：我们有四个不同的层次：公司黑盒子、系统黑盒子、系统内的逻辑设计以及物理实现。Bwi大力在线
Bwi大力在线
·每个层次内的多个视图：在这个简单示例中，我们在每个层次上展示了一个动态视图和静态视图。Bwi大力在线
Bwi大力在线
·必须保持层次间的一致性：如果对域模型作出了更改，则更改也一定会影响到较低层次。举例来说，如果零售商决定为其产品提供维护合同，分析师就会将MaintenanceContract 添加到域模型，并将其改进为其物理表现形式。对于维护大型系统来说，同步所有层次是很重要的。因为提交了增强请求，所以分析师执行对相应细节层次的影响评估。一些增强请求影响域层次（并且因此影响所有后续层次）。其他请求只影响物理层次。
扩展层次以支持企业解决方案
既然我们已经展示了带有四个抽象层次的简单示例，现在就让我们扩展这个方法来支持 IT 企业的解决方案。图 9 展示了一个 Rational 统一过程 (Rational Unified Process，RUP) 配置，它将项目产品组织到定义完善的抽象层次中。
