所谓软件架构，指的是软件系统的整体结构，包括软件子元素，这些元素的外部属性以及元素元素之间的关系。
这个定义包含了以下三层意思：
（1）软件架构是对系统的抽象。它不仅规定了系统有哪些主要软件元素或模块，还定义了这些元素之间是如何交互的。它并不暴露每个元素的内部属性（也叫局部信息），也就是说每个子模块的私有信息是不划归到软件架构的范畴的。需要注意的是，每个元素的外部属性依然是软件架构的一部分。这里所谓的外部属性，指的是一个元素对其他元素所承担的责任实体，包括：提供的服务，所需的服务，性能特征，错误处理以及资源的使用。
软件元素，一般分为组件，连接器和数据三种。一个组件是软件指令和内部状态的一个抽象单元，通过其接口提供对于数据的转换。一个连接器是对于组件之间的通讯、协调或者合作进行仲裁的一种机制。一个数据是组件通过一个连接器接收或发送的信息元素。
数据的例子包括字节序列，消息，编码过的参数以及序列化过的对象，但不包括那些永久驻留或组件的私有信息。连接器的例子包括RPC远程过程调用、消息传递协议和数据流等。
（2）每个软件系统都有一个架构。每个系统都是由一个或多个元素组成，并且这些元素之间都存在一定的关系。只有一个元素的系统是最简单的一种情况。
（3）系统可能有多个视图。从不同的角度，系统可能获得不同的结构表示图。单单其中一个视图无法代表软件架构。软件架构是所有这些视图的总和。在一般情况下，你可以选择其中一个或几个结构视图用以对软件系统进行分析，理解或团队间沟通。
软件架构勾画了一个公用的框图，可供不同的人参阅，学习和理解。这使得我们对软件系统的理解和沟通更为顺畅，具体体现为：
（1）与用户讨论和协商软件需求；
（2）让客户及时了解我们的软件开发进展及大致成本；
（3）对实施管理层的决定和人力调配起到一定帮助作用。
（2）可以帮助管理者做人力和其他开发成本预算。
（3）可以帮助组织开发文档。
（4）可以对软件的集成起到帮助作用；
包括但不限于：安全性、可扩展性、可修改性、可重用性、性能等
软件架构把变化归为三类：
（1）局部性变化。如，修改单个子元素或组件；
（2）大范围变化。如，多个组件需要被修改；
（3）架构性变化。如修改整个系统拓扑视图，修改组件之间的通信模式或变更元素间的协调机制。
一个好的软件架构，一定是在改动最少的情况下，能够很好的自适应各种变化。
（1）如建筑领域一样，软件架构应充当一个框架的作用。我们可以往框架填充软件组件。也就是说，软件元素是可以作为插件集成到系统里的；
（2）通过把某些软件功能划分到某个或某几个软件元素，我们可以分而治之，各个击破；
（3）可以提前通过架构分析出哪些软件元素可能对项目的成功存在风险，进而对资源分配进行调整。
原文地址：http://blog.csdn.net/acs713/article/details/25793367
