位于不同级别的模式
 
    模式存在于多个不同的抽象级别中。考虑另一个示例（这次所处的抽象级别比源代码要高一级）：

    您要设计一个基于Web的报价应用程序，其中包含大量业务和表示逻辑，这些逻辑反过来依赖大量平台软件组件来提供适当的执行环境。如何在高级别组织系统以使其在具有灵活、松耦合性的同时仍具有高内聚性？

    此问题的解决方案之一涉及到按一系列层来组织系统，每层包含大致位于同一抽象级别的元素。随后，确定每一层中的依赖性，并确定采用严格还是宽松的分层策略。接着，决定是打算创建自定义的分层方案，还是采用以前由其他人记录的分层方案。在本例中，假设您决定使用众所周知的分层策略：表示、业务逻辑和数据访问各占一层。图2显示了分层方案的可能外观。

图2 报价应用程序的层

    如果您总是按这种方式设计系统，说明您已经在不依赖于任何广义模式的情况下使用该模式。即便如此，您还可能因多种原因而希望了解支撑这种设计方法的模式。您可能迫切想知道为何经常以这种方式构建系统，或者可能在寻找更理想的方法来解决此模式不能完全解决的问题。使用层作为高级别组织方法是Layers（层）模式[Buschmann96]中描述的完善模式。图3显示了该模式的简化版本。

图3 简化的Layers模式

    这个简单的应用程序组织策略有助于解决软件开发中面临的两个挑战：依存关系的管理和对可交换组件的需求。如果在构建应用程序时没有一个考虑周全的依存关系管理策略，会导致组件易损坏且不牢靠，从而导致对它们进行维护、扩展和替代时存在较大的困难，而且成本较高。

    Layers模式中的工作机制比Singleton中的工作机制更精细。对于Layers，首次协作是在设计时发生在类之间，这是由于分层组织将对更改源代码所带来的影响局部化，从而防止所做的更改贯穿到整个系统。第二次协作发生在运行时：某层中相对独立的组件变得可与其他组件交换，再一次使系统其余部分不受影响。

    尽管Layers模式的通用性足以应用于诸如网络协议、平台软件和虚拟机之类的领域，但是它无法解决企业类业务解决方案中存在的某些特定问题。例如，除通过分解来管理复杂性（由Layers解决的基本问题）外，业务解决方案开发人员还需要进行适当组织，以便有效地重复使用业务逻辑并保留与昂贵资源（如数据库）的重要连接。解决此问题的方法之一就是使用Three-Layered Application（三层应用程序）模式。图4显示了该模式的简化说明。

图4 简化的Three-Layered Application

    同样，在模式(Three-Layered Application)和模式应用程序（报价应用程序分层模型）之间存在区别。模式是有关应用程序组织主题的通用问题-解决方案对，而模式应用程序是通过创建具体的层来解决非常具体的问题。