分层

应当把子系统组织成分层结构，构架的上层是应用程序专用子系统，构架的低层是硬件和操作专用子系统，中间件层是通用服务。

下面是一个四层构架的示例。

• 顶层是应用程序层，它包括应用程序专用的服务。
• 下面一层是业务专用层，它包括在一些应用程序中使用的业务专用构件。
• 中间件层包括各个构件，例如 GUI 构建器、与数据库管理系统的接口、独立于平台的操作系统服务以及电子表格程序、图表编辑器等 OLE 构件。
• 底层是系统软件层，它包括操作系统、数据库、与特定硬件的接口等构件。

分层结构始于最初略的功能层次，然后逐步发展成多个更为具体的功能层次。

分层指南

分层从逻辑上将子系统划分成许多集合，而层间关系的形成要遵循一定的规则。通过分层，可以限制子系统间的依赖关系，使系统以更松散的方式耦合，从而更易于维护。

子系统的分组标准包含以下几条规则：

• 可见度。各子系统只能与同一层及其下一层的子系统存在依赖关系。
• 易变性。
  • 最上层放置随用户需求的改变而改变的元素。
  • 最底层放置随实施平台（硬件、语言、操作系统、数据库等）的改变而改变的元素。
  • 中间的夹层放置广泛适用于各种系统和实施环境的元素。
  • 如果在这些大类中作进一步划分有助于对模型进行组织，则添加更多的层。
• 通用性。一般将抽象的模型元素放置在模型的低层。如果它们不针对具体的实施，则倾向于将其放置于中间层。
• 层数。对于小型系统，三层就足够了。对于复杂系统，通常需要 5-7 层。无论复杂程度如何，如果超过 10 层，就需要慎重考虑了。层数越多，越需慎重。以下列出了一些经验法则：

类的数量	层数
0 - 10	无需分层
10 - 50	2 层
25 - 150	3 层
100 - 1000	4 层

特定层中的子系统和包只应同一层及其下一层的子系统存在依赖关系。如果不这样限制依赖关系，将会导致构架退化，使系统脆弱并难于维护。

如果子系统需要直接访问低层服务，则属于例外：应理智地决定如何处理整个系统所需的基本服务（如打印、发送消息等）。如果解决方案是在中间各层之间有效地实施穿透式调用，将消息限制在低层就毫无意义了。