本节书摘来自华章出版社《实用软件架构：从系统环境到软件部署》一书中的第2章，第2.2节，作者：[印]蒂拉克·米特拉（Tilak Mitra）著，爱飞翔 译，更多章节内容可以访问云栖社区“华章计算机”公众号查看。
2.2 软件架构是什么
系统工程领域中的很多研究团体和个人，都对软件架构给出了自己的解读，他们从不同的视角阐述了怎样才能把软件系统的架构较好地表示出来。这些解读方式或视角，都有其合理的地方，它们本身并没有问题。笔者认为，Bass、Clements和Kazman (2012)给出的解释抓住了软件架构的本质：
程序或计算机系统的软件架构，指的就是系统的结构，该结构由软件组件、外部可见的组件属性，以及它们之间的关系而构成。
那么，这个定义意味着什么呢？
这个定义想要强调的意思，是说软件架构由粗粒度的构件（也就是软件组件）组成，这些构件，可以视为架构的构建块（building block，也称为组成单元或构造块）。我们把这种架构的构建块（architecture building block）简称为ABB。每一个软件组件，或者说每一个ABB（以后笔者会交替地使用这两个词），都具备一些外部可见的属性，它会把这些属性展示给架构中的其他ABB。至于组件的内部细节究竟应该如何来设计和实现，则与系统的其余部分没有关系。软件组件是作为黑盒而存在的，也就是说，它的内部细节不会暴露给外界，它所暴露的只是一些属性，系统中的其他组件，可以协同利用这些属性，把系统想要展示给用户的能力实现出来。软件架构不仅要在最佳的粒度上确定系统中的ABB，而且还要根据其展示出来的属性以及所要支持的能力，来描述每一个ABB的特征。软件架构师必须很好地确定出系统中的ABB及其属性与能力，这样才能把握住软件架构的要义。为此，我们要把确定ABB及其属性与能力所用的那套办法，用一种简洁、清晰，而又易于理解和交流的形式，正式地描述出来。
软件工程中的架构工作，指的是把系统分解或划分为一系列部件，使我们能够对每个部件都进行模块式的、迭代式的、渐进式的和独立式的开发。正如早前所说，这些部件之间可能会具备某些关系，当我们把这些部件交织起来或汇集起来时，应用程序的软件架构（也就是系统）就搭建出来了。
很对人对架构与设计之间的区别有着一些困惑。按照Bass、Clements和Kazman (2012)的说法，所有的架构都是设计，但设计却不一定是架构。某些设计模式确实可以令系统更加灵活、更加易于扩展，同时也可以使系统所要满足的边界条件得以明确，把这些模式说成架构模式，是没有问题的。但更具体地来说，架构所要强调的意思是把ABB当成黑盒，而设计所注重的则是软件组件的配置、定制以及内部的工作机理等方面。就软件组件来说，架构所关注的问题，仅仅是该组件的外部属性，而设计所关心的问题则更加宽泛，它不一定只会谈论该组件外部的那些属性，同时还有可能提到组件内部的实现细节。
值得注意的是，软件架构的原则是可以反复运用的，如图2-1所示。
我们可以把图2-1中代表Classroom（教室）的软件组件C1，当成系统架构的一部分。除了C1之外，架构中还有其他一些组件，架构师可以把组件C1连同其属性、功能方面与非功能方面的能力，以及该组件与其他软件组件之间的关系，一并分享给系统设计者。像这种由各ABB之间的相互关系及其外部可见属性所构成的集合，就叫作架构蓝图（architecture blueprint）。设计者在分析了C1这个软件组件之后，感觉它还可以细分为三个更小的组件，也就是代表Table（桌子）对象的C11，代表Chair（椅子）对象的C12，以及代表Blackboard（黑板）对象的C13，每一个小的组件，都具备一些可供复用的功能，可以用来实现C1所要具备的属性。设计者会对C11、C12、C13这三个组件及其接口进行细化，并把这三个组件及其接口与关系，当成C1这个软件组件的架构单元。然后，又可运用同一种思路，分别针对C11、C12及C13继续进行细化设计，以解决其内部的实现问题。因此，我们可以把一个庞大而复杂的系统，分解为多个小的组成部分，然后对每一个部分继续进行细化，这种做法，就是对软件架构原则的递归式运用。
正如早前所说的那样，之所以要给系统制定架构，是为了厘清系统的范围，使其能够用适当的ABB来满足行为和质量方面的目标。无论什么样的系统，其架构都要能够较好地为利益相关者所理解，此处所说的利益相关者，既包括使用本架构来进行下游设计和实现的人，也包括给本架构的定义、维护及增强工作提供资金的人。本章稍后就会更加详细地讨论这些方面，不过笔者先要在这里强调一点，那就是沟通的重要性：架构是一种沟通媒介，通过它，我们可以和利益相关者就IT系统进行讨论。
