这一章介绍了8个架构模式：
分层 Layers
管道和过滤器 Pipes and Filters
黑板 Blackboard
中间人 Broker
模型-视图-控制器 Model-View-Controller, MVC
表示-抽象-控制 Presentation-Abstraction-Control
微内核 Microkernel
反射 Reflection
2.1 导言
在模式系统中，架构模式位于最高层，有助于规范应用程序的基本结构。后续的每项开发活动都受这种结构左右，如子系统的详细设计
关于架构模式的选择：每个架构模式都有助于获得特定的系统整体特征，如用户界面的可适应性。应根据要创建的应用程序的总体特征来选择架构模式。选择特定的架构模式前，探索多个备选模式也有所帮助。即便解决的问题相同或非常接近，不同架构模式的效果也不同。然而，大多数软件系统仅根据一个架构模式是打造不出来的。多数系统的设计，需要结合使用多个模式。进一步讲，无论是单个架构模式，还是多个架构模式组合，都不是完备的软件架构，而只给软件系统提供了结构框架，必须进一步规范和细化。这包括集成这个框架和应用程序功能，细化软件系统的组件及它们之间的关系，而这些任务可能需要借助设计模式和成例来完成。选择一个或多个架构模式只是软件系统架构设计的第一步。
2.2 从混乱到有序
定义系统的架构，意味着将系统粗略地划分成多个部分。我们通常知晓各个方面。但无力将混乱的局面组织成可行的结构。Ralph Johnson称这种情况为“泥球”。这通常就是最初面临的局面，我们必须将其变成更有序的结构。
基于应用领域已知的规则来切分这个泥球无助于解决问题，原因有多个。一方面，最终的软件系统将包含大量与应用领域没有直接关系的组件，manager和help functionality就是这样的典型。另一方面，我们不仅要求系统能正常运行，还要求它具备一些与应用程序功能没有直接关系的特质，如可移植性、易于维护、易于理解、稳定等。(bruce: 非功能性需求不属于任何业务领域)
2.2.1