体系结构模式描述了软件系统的基本结构化组织方案。它提供了一套预定义的子系统，规定它们的职责，并包含用于组织它们之间关系的规则和指南。
8种体系结构模式：层、管道和过滤器、黑板、代理者、模型—视图—控制器、表示—抽象—控制、微核、映像。
把上8种体系结构模式分成四类：
● 从混沌到结构。支持把整个系统任务以受控的方式分解成可协作的子任务。这一类包括层模式、管道和过滤器模式以及黑板模式。
● 分布式系统。这类包含一种模式，即代理者模式，并涉及到其他种类中的两个模式，即微核模式、管道和过滤器模式。代理者模式为分布式应用提供了一个完整的基础结构。它的基础体系结构很快被对象管理组（OMG）所标准化。
● 交互式系统。该类由两种模式构成，即模型—视图—控制器模式和表示—抽象—控制模式。这两个模式都支持具有人机交互的软件系统的构建。
● 适应性系统。映像模式和微核模式强有力地支持应用的扩展以及它们对进化技术和变更功能需求的适应性。
绝大多数软件体系结构不能仅依据一个系统结构模式来构建。它们必须支持几种用不同系统结构模式来说明的系统需求。
1、 从混沌到结构
与该类别相关的三种体系结构模式：层、管道和过滤器以及黑板，它们提供不同类型的高层系统划分。
层模式有助于构建这样的应用：它能被分解成子任务组，其中每个子任务处于一个特定的抽象层次上。
管道和过滤器模式为处理数据流的系统提供了一种结构。每个处理步骤封装在一个过滤器组件中。数据通过相邻过滤器之间的管道传输。重组过滤器可以建立相关系统族。
黑板模式对于无确定性求解策略的问题比较有用。在黑板模式中有几个专用子系统收集其知识以建立一个可能的部分解或近似解。
详细模式应用介绍：以网络分层的例子介绍了层模式；以编译器软件的例子介绍了管道和过滤器模式；以语音识别软件的例子介绍了黑板模式。具体参考书中18~55页的内容。
2、 分布式系统
分布式系统的优势有经济性、性能与可扩展性、固有分布性、可靠性（在大多数情况下，网络上的一台机器或多处理器系统中的一个CPU的崩溃不会影响到系统的其余部分。中心节点（文件服务器）是明显的例外，但可以采用备份系统来保护）。但是分布式系统有一个显著的缺点：分布式系统与集中式系统相比需要完全不同的软件。
与该类别相关的三种体系结构模式：
管道和过滤器模式为处理数据流的系统提供了一种结构。每个处理步骤封装在一个过滤器组件中。数据通过相邻过滤器之间的管道传输。重组过滤器可以建立相关系统族。这种模式与分布相比，更经常用于构建一个应用程序的功能内核。
微核模式应用于必须能够适应变更系统需求的软件系统。这种模式把最小功能内核同扩展功能和特定客户部分分离开来。微核也可作为插入到这些扩展中和协调其协作的套接字。
代理者模式可以用于构建带有隔离组件的分布式软件系统，该组件通过远程服务调用进行交互。代理者组件负责协调通信，诸如转发请求以及传送结果和异常。
代理者系统提供了两种核心技术集成的途径：分布技术和对象技术。本书以城市信息系统（CIS）介绍了代理者模式，详细具体参考书中P55-69。
代理者模式已有的应用有COBRA（公共对象请求代理系统结构）、IBM SOM/DSOM、微软OLE/COM/DCOM、万维网（WWW）、ATM-P（西门子公司建立基于ATM（异步传输方式）的电信交换系统）。
3、 交互式系统
交互式系统的内核基于系统功能需求，通常保持稳定。然而，用户接口常常要经受变化和改建。这就需要能支持用户接口改建而特定应用程序或低层软件的数据模型不产生重要影响的系统结构。这里提供两种模式，它们能够为交互式系统提供一个基本的结构化组织：
模型—视图—控制器（MVC）体系结构模式将一个交互式应用程序分为三个组件。模型包含核心功能和数据。视图向用户显示信息。控制器处理用户输入。视图和控制器共同构成了用户接口。变更—传播机制确保了用户接口和模型之间的一致性。
表示—抽象—控制（PAC）体系结构模式以合作agent的层次形式定义了交互式软件系统的一种结构。每个agent负责应用程序功能的单一特定方面，并且由表示、抽象和控制三个组件构成。这种细分将agent的人机交互部分与其功能内核和它与其他agent的通信分隔开来。
4、 适应性系统
系统随着时间演化——添加新的功能和更改现有的服务。它们必须支持新版本的操作系统、用户接口平台或第三方组件。适应新的标准或硬件平台也是必要的。应对变化的设计成为我们在描述一个软件系统的体系结构时应该主要考虑的方面。这里提出了两种模式：
微核模式应用于必须能够适应变更系统需求的软件系统。这种模式把最小功能核心同扩展功能和特定客户部分分离开来。微核也可作为插入到这些扩展中并协调其协作的套接字。微核模式提供了一个“即插即用”的软件环境，使得你容易地连接扩展部分并把它们同系统的核心服务集成在一起。
映像模式为动态地改变软件系统的结构和行为提供了一种机制。它支持诸如类型结构和函数调用机制等基本方面的修改。在这种模式中，一个应用程序可分成两部分。一个元层次提供所选系统属性的相关信息并使软件含自述信息。一个基本层次包括应用程序逻辑。它的实现建立在元层次之上。改变保存在元层次上的信息会影响其后的基本层次上的行为。
五、设计模式
八种设计模式：整体—部分、主控—从属、代理、命令处理器、视图处理程序、转发器—接收器、客户机—分配器—服务器、出版者—订阅者。
设计模式分类：
● 结构化分解。此类别包含的模式支持将子系统和复杂组件适当地分解成相互合作的部分。
整体—部分模式是我们在此类别中能体会到的最普遍的模式。它被广泛应用于构造复杂组件。
● 工作的组织。此类别包含的模式定义了组件之间如何协作来共同解决复杂问题。我们描述的主控—从属模式有助于构成服务所需的容错或计算精度的计算。它同时支持将服务分解成相互对立的部分并能并行执行。
● 访问控制。这种模式保护和控制对服务或组件的访问。这里描述的代理模式允许客户机与组件的代表通信而不是与组件本身通信。
● 管理。次类别包含的模式将同类对象集、同类服务集、同类组件集视为一个整理来处理。我们描述两种模式：命令处理器模式处理用户命令的管理和协议，而视图处理程序模式描述在一个软件系统中如何管理视图。
● 通信。次类别中的模式有助于构成组件间的通信。有两种模式用于出来进程间通信问题：转发器—接收器模式处理对等通信，客户机—分配器—服务器模式描述在一个客户机—服务器结构中的位置透明通信。
出版者—订阅者模式有助于合作组件之间保持数据一致性任务。为了达到这一点，它能实现单向更改传播：一个出版者通知任意数目的订阅者有关对于其状态的更改。
六、惯用法
惯用法是特定程序设计语言中的的低层模式。惯用法描述如何使用给定语言的特征来实现组件的特殊方面或它们之间的关系。
一个惯用法有助于用常用的程序设计语言解决经常遇到的问题，如内存管理、对象创建、方法命名、为了易读性而进行的源代码格式化、特定库构件的有效使用等。解决这类问题的方法有：阅读有经验程序员写的源代码；理解程序设计中设计人员使用的模式；代码风格；计数指针等。
计数指针惯用法使C++中的动态分配共享对象的内存管理更为容易。它引入了实体类的一个引用计数器，其中的计数器由句柄对象更新。客户机只有凭借句柄通过重载operator->()来访问实体类对象。
