ANSI/IEEE 610.12-1990软件工程标准词汇对于体系结构定义是：“体系架构是以构件、构件之间的关系、构件与环境之间的关系为内容的某一系统的基本组织结构以及知道上述内容设计与演化的原理(principle)”。

　　Mary Shaw和David Garlan认为软件体系结构是软件设计过程中，超越计算中的算法设计和数据结构设计的一个层次。体系结构问题包括各个方面的组织和全局控制结构，通信协议、同步，数据存储，给设计元素分配特定功能，设计元素的组织，规模和性能，在各设计方案之间进行选择。Garlan & Shaw模型的基本思想是：软件体系结构={构件(component),连接件(connector)，约束(constrain)}．其中构件可以是一组代码，如程序的模块；也可以是一个独立的程序，如数据库服务器。连接件可以是过程调用、管道、远程过程调用(RPC)等，用于表示构件之间的相互作用。约束一般为对象连接时的规则，或指明构件连接的形式和条件，例如，上层构件可要求下层构件的服务，反之不行；两对象不得递规地发送消息；代码复制迁移的一致性约束；什么条件下此种连接无效等。

　　关于架构的定义还有很多其他观点，比如Bass定义、Booch & Rumbaugh &Jacobson定义、Perry & Wolf模型[7]、Boehm模型等等，虽然各种定义关键架构的角度不同，研究对象也略有侧重，但其核心的内容都是软件系统的结构，其中以Garlan & Shaw模型为代表，强调了体系结构的基本要素是构件、连接件及其约束（或者连接语义），这些定义大部分是从构造的角度来甚至软件体系结构，而IEEE的定义不仅强调了系统的基本组成，同时强调了体系结构的环境即和外界的交互。

　　什么是模式
　　模式（Pattern）的概念最早由建筑大师Christopher Alexander于二十世纪七十年代提出，应用于建筑领域，八十年代中期由Ward Cunningham和Kent Beck将其思想引入到软件领域，Christopher Alexander将模式分为三个部分：首先是周境（Context，也可以称着上下文）,指模式在何种状况下发生作用；其二是动机（System of Forces）,意指问题或预期的目标；其三是解决方案（Solution）,指平衡各动机或解决所阐述问题的一个构造或配置（Configuration）。他提出，模式是表示周境、动机、解决方案三个方面关系的一个规则，每个模式描述了一个在某种周境下不断重复发生的问题，以及该问题解决方案的核心所在，模式即是一个事物（thing）又是一个过程(process)，不仅描述该事物本身，而且提出了通过怎样的过程来产生该事物。这一定义已被软件界广为接受。

　　软件模式的应用对软件开发产生了重大的作用，主要表现在：

　　软件模式是人们在长期的设计软件、管理组织软件开发等实践中大量经验的提炼和抽象，是复用软件设计方法、过程管理经验的有力工具。模式类似于拳击中的组合拳，它提供了一系列软件开发中的思维套路。如，通过模式的使用，有利于在复杂的系统中产生简洁、精巧的设计。
软件模式为我们提供了一套简洁通用的设计、管理、组织方面的词汇，同时模式也为我们提供了一个描述抽象事物的规范标准，可大大促进软件开发过程中人与人之间的交流，而软件开发中的交流是至关重要的，“软件项目失败的原因最终都可追溯到信息没有及时准确地传递到应该接收它的人”。
架构和模式的关系
　　因为架构(Architecture)和模式(Pattern)在当前的软件开发中经常地被提及，可是很多人容易混淆这两个术语，而对此，学术界也没有一个非常统一的定义。

　　架构和模式应该是一个属于相互涵盖的过程，但是总体来说Architecture更加关注的是所谓的High-Level Design,而模式关注的重点在于通过经验提取的“准则或指导方案”在设计中的应用，因此在不同层面考虑问题的时候就形成了不同问题域上的Pattern。模式的目标是，把共通问题中的不变部分和变化部分分离出来。不变的部分，就构成了模式，因此，模式是一个经验提取的“准则”，并且在一次一次的实践中得到验证，在不同的层次有不同的模式，小到语言实现(如Singleton)大到架构。在不同的层面上，模式提供不同层面的指导。根据处理问题的粒度不同，从高到低，模式分为3个层次：架构模式(Architectural Pattern)、设计模式(Design Pattern)、实现模式(Implementation Pattern).架构模式是模式中的最高层次，描述软件系统里的基本的结构组织或纲要，通常提供一组事先定义好的子系统，指定它们的责任，并给出把它们组织在一起的法则和指南。比如，用户和文件系统安全策略模型，N-层结构，组件对象服务等，我们熟知的MVC结构也属于架构模式的层次。一个架构模式常常可以分解成很多个设计模式的联合使用。设计模式是模式中的第二层次，用来处理程序设计中反复出现的问题。例如，[GOF95]总结的23个基本设计模式——Factory Pattern, Observer Pattern等等。实现模式是最低也是最具体的层次，处理具体到编程语言的问题。比如，类名，变量名，函数名的命名规则；异常处理的规则等等。

　　相对于系统分析或者设计模式来说，体系结构从更高的层面去考虑问题，所以关注的问题就体现在“不变”因素上，比如系统部署中，更加关心应用程序的分层分级设计，而在这个基础之上提出的部署方案，才是架构考虑的重点。体系结构关心应用程序模式，更加体现在通过技术去解决这些业务差异带来的影响，关心是否是分布式应用程序，关心系统分层是如何设计，也关心性能和安全，因此在这样的情况之下，会考虑集群，负载平衡，故障迁移等等一系列技术。

　　希望通过定义的方式来区分架构和模式是不太可能的，因为本来就是交互交叉和提供服务的，它实际上是架构模式，而不是设计模式。在大部份情况下，表现为下面几个设计模式之一：Strategy模式、Mediator模式、Composite模式、Observer模式。对于熟悉架构设计的系统架构师而言，似乎可以用如下来解释架构和模式之间的关系：架构是Hight-Level Design,着眼于不同业务中共性的解决方案，而模式是General Principle(通用原理)。

　　模式对于开发人员和体系结构设计者非常有用，因为它们：

　　记录能够正常工作的简单机制。
　　为开发人员和体系结构设计者提供通用的词汇和分类法。
　　允许以模式组合的方式简明扼要地描述方案。
　　允许重复使用体系结构、设计和实现决策。
　　模式可以记录简单机制
　 模式描述给定上下文中反复出现的问题，并基于一组指导性影响因素来建议解决方案。解决方案通常是一种简单的机制，是为了解决模式中所标示出的问题而一起工作的两个或多个类、对象、服务、进程、线程、组件或节点之间的协作。
　
 　 您正在构建一个报价应用程序，其中有一个类负责管理系统中的所有报价。很重要的一点是，所有报价都应与该类的一个（而且只与一个）实例进行交互。如何构造您的设计，以便从该应用程序中只能访问该类的一个实例？

  　解决该问题最简单的方案就是创建一个具有私用构造函数的QuoteManager类，以便任何其他类都不能实例化它。此类包含QuoteManager的一个静态实例，并使用名为GetInstance()的静态方法返回。此代码大体如下所示：

　public class QuoteManager
　{
  　  //注意：仅适用于单线程应用程序
  　  private static QuoteManager _Instance = null;

   　 private QuoteManager() {}

   　 public static QuoteManager GetInstance()
   　 {
      　  if (_Instance==null)
      　  {
      　      _Instance = new QuoteManager ();
      　  }
      　  return _Instance;
   　 }　

   　 //... QuoteManager提供的函数
　}

　　您可能已经像其他许多开发人员那样通过类似的方式解决过类似的问题。实际上，注意反复出现的问题并寻求解决方案的模式作者已经屡次发现了这种实现，提取出了通用解决方案并将这种问题-解决方案对称为Singleton模式[GOF95]。

　　问题-解决方案对模式

　　图1 简化的Singleton模式

　　通过将图1中简化的模式示例与QuoteManager源代码进行比较，阐明了模式（通用问题-解决方案对）和模式应用程序（针对非常具体的问题的具体解决方案）之间的区别。模式级别的解决方案是多个类之间简单但极其顺畅的协作。模式中的通用协作专门适用于QuoteManager类，提供了用来控制报价应用程序中实例化的机制。显然，您可以稍微修改一下某种模式以满足局部的特定要求，所以同一种模式可以应用于无数个应用程序。

　　所编写的模式提供了一种记录简单且经过证实的机制的有效方法。模式是以特定格式编写的，这一点对于装载复杂思想的容器非常有用。这些模式在被记载和起名之前，就早已存在于开发人员的大脑及其代码中。

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

　　您要设计一个基于Web的报价应用程序，其中包含大量业务和表示逻辑，这些逻辑反过来依赖大量平台软件组件来提供适当的执行环境。如何在高级别组织系统以使其在具有灵活、松耦合性的同时仍具有高内聚性？
　　此问题的解决方案之一涉及到按一系列层来组织系统，每层包含大致位于同一抽象级别的元素。随后，确定每一层中的依赖性，并确定采用严格还是宽松的分层策略。接着，决定是打算创建自定义的分层方案，还是采用以前由其他人记录的分层方案。在本例中，假设您决定使用众所周知的分层策略：表示、业务逻辑和数据访问各占一层。图2显示了分层方案的可能外观。

　　图2 报价应用程序的层

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

　　图3 简化的Layers模式

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