通过本章前面的讨论，我们了解到：

Ÿ   软件系统是由不同粒度的软件单元层层递归构成的，如子系统、模块、类；

Ÿ   由于在实践中所处的位置不同，同一个软件单元在不同实践者眼中的粒度可能不同，如实现Zip算法的实用类，它的开发者至少认为它是个复杂模块；

Ÿ   子系统也有架构，如报表子系统；

Ÿ   即使是同一系统内部，子系统不同，所采用的架构也有可能不同，如报表子系统采用事务脚本架构，而拓扑子系统采用领域模型架构模式；

Ÿ   框架和架构既有区别又有联系，前者是复合组件特例，后者是复合组件的大局设计；

Ÿ   框架也需要架构设计，如Struts作为著名框架自然有其架构；

Ÿ   反过来，可以通过架构框架化达到“架构重用”的目的，如很多人都在用Spring框架提供的控制反转和依赖注入来构建自己的架构。

本节主要是总结软件架构概念的内涵，并理解软件架构的适用范围（即外延）。

2.4.1  理解架构

真实的软件其实是“由组件递归组合而成”的：

Ÿ   组件的粒度可以很小，也可以很大；任何粒度的组件都可以组合成粒度更大的整体。即所谓的粒度多样性问题；

Ÿ   组件粒度的界定，必须在具体的实践上下文中才有意义；你的大粒度组件，对我而言可能是原子组件。即所谓的粒度相对性问题。

由此，我们不能不联想到Composite模式。Composite模式用于表示“部分－整体”的层次结构，可以用来描述软件的递归组合的本质。图2-11运用了Composite模式来刻画更加真实的软件。

本图借助UML类图的语法，表达了一般意义上的“组件合成”场景：组件分为原子组件和复合组件两种；在特定的实践上下文中，原子组件是不可再分的；复合组件是由其他组件（既可以是原子组件，又可以是复合组件）组合而成的；无论是原子组件还是复合组件，它们之间都可以通过交互来完成更复杂的功能。

是时候为“软件架构”找准位置了。

答案看上去惊人的简单，如图2-12所示。此图可以用一句话概括：“作为复合整体的软件单元才有架构，架构规定了它如何被设计的重要决策”。

软件架构并不是所有的组件内部的设计都不关心，而是仅仅不关心“在架构设计阶段没有必要进一步分解”的软件单元的内部细节；另外，也不是要将所有设计决策事无巨细地落实，而是重点关注“重要决策”。软件架构设计的决策范围，应该着重放在“影响全局”的设计上，而不是关注所有设计细节。对此，Len Bass等人在《软件架构实践》一书中已经明确指出：

架构中包含了关于各元素应如何彼此相关的信息。也就是说，架构必须省略各元素中与交互无关的某些信息。因此，架构首先是对系统的抽象，该抽象去除了不影响它们如何使用、其他元素如何使用以及如何与其他元素关联或交互的细节。在几乎所有的现代系统中，各元素都是通过接口实现交互的，而这些接口又将各元素的细节划分为公有和私有两大类。根据这种划分，架构属于公有部分，而私有部分——即仅与内部具体实现有关的细节——是不属于架构的。

由此可见，软件系统架构关注的是涉及元素之间如何交互的大局，而必须将局部性的细节忽略。其实，关注大局，把握整体，不仅仅是软件系统架构学科的主题，还是所有系统科学研究的对象，钱学森就说过：“什么叫系统？系统就是由许多部分组成的整体，所以系统的概念就是要强调整体，强调整体是由相互关联、相互制约的各个部分所组成的。”

推广开去，其实任何作为复合整体的复杂事物都可能有架构，比如一本书、一幢建筑物。那本“永不褪色的经典”《如何阅读一本书》中就说：“每一本书的封面之下都有一套自己的骨架（Every book has a skeleton hidden between its boards）。”

2.4.2  回到实践

虽然我们最常听到的说法是“软件系统的架构”，但其实未必是完整的软件系统才有架构。在实际的软件实践中，系统、子系统和框架往往都需要进行架构设计。如图2-13所示。

例如，航空航天领域的系统往往极为复杂，这样一来，总的系统需要配备系统架构师，子系统有时也会分别单独配备架构师。

又例如，著名的用友华表Cell 组件是标准的报表处理ActiveX组件，它提供几百个编程接口。虽然在用户看来它只是“开盒即用”的ActiveX组件，但这样一个提供强大的制表能力、拥有丰富的单元格类型的报表解决方案，当然需要精心的架构设计。

再例如，随着面向服务架构（SOA，Service Oriented Architecure）被越来越多的人所接受，基于组件的软件工程（CBSE，Component Based Software Engineering）也为更多的人所认识。在此种情况下，整个系统的架构模式是SOA，而每个组件本身也有自己的架构设计——在实践中不了解这一点会很危险。