何为软件架构？

何为软件架构？

What is software architecture?

透过本书，你将学会如何利用模型及抽象概念去解释软件系统，确切地说是系统的软件架构。设计会影响到系统的优劣，例如，系统是否处理快速、安全或易于修改。无论你是将设计记录在精心标记过的活页夹中，还是直接记在脑海中，设计都会对系统的优劣产生影响。

架构与详细设计　软件系统的设计由开发者的决策与意图组成。设计可以被划分为软件架构(通常简称架构)和详细设计。

在实践过程中，你通常会发现，很难将架构与详细设计区别开来。无独有偶，虽然专家们普遍认同架构的主干，但在一些细枝末节上存在分歧，例如，何时终止架构设计，进而开始详细设计。或许把架构与详细设计之区别叙述得最明了的，还要数该领域的两位领导者，Mary Shaw与David Garlan(Shaw & Garlan, 1996)：

随着软件系统规模与复杂度的增长，整个系统结构的设计与规格说明书变得更为重要，甚至超过对算法与运算数据结构的选择。系统的结构问题包括：系统的组织，如组件的组合方式；整体的控制结构；用于通信、同步及数据访问的各种协议；针对设计元素的功能分配；设计元素的组合方式；物理分布；伸缩能力及性能；演进的维度；在多个可选设计方案中作出选择。这些都是软件架构层面的设计。

定义　尽管已提出的软件架构定义不胜枚举，不过，人们普遍认同架构可以处理那些宏观的、影响广泛的软件设计问题。其中被普遍接受的定义来自卡内基·梅隆大学软件工程研究所(SEI)(Clements et al.，2010)：

计算系统的软件架构是解释该系统所需的结构体的集合，其中包括：软件元素、元素之间的相互关系，以及二者各自的属性。

该定义罗列了软件架构至关重要的要素：元素、关系及属性。然而，并不能简单地认为就是这些结构体组成了架构，而是说架构是解释该系统所需的结构体的集合。

譬如说，让我们设想美国的架构。连小学生都知道美利坚合众国由50个州组成，并在课堂上记住了这些州的位置。然而，光有这些结构信息并不足以理解这个国家。因此，学生们在随后的课程中，进一步地了解到各州在成立时的面积大小、资源的差异，还有各州面积与人口对国家立法机构的影响。随着了解的逐步深入，他们就可以理解为何每个州的参议员名额都是两个，即使人口最多的州与人口最少的州，其人口数相差了60多倍。

这一类比的价值在于：若要理解某个系统(例如，美国)的架构，就不能死记硬背它的结构，而应该多了解一些相关知识。这也让我们有机会预览本书的一个主题：即使没有系统的完整模型，仍然可以对系统进行分析。如果要回答类似“美国有哪些城市可以乘船前往？”的问题，则无须美国的完整模型。

什么属于架构层面的内容　将架构定义为一组能够帮助我们对系统进行推断与分析的要素，有助于我们专注于架构的目的(分析)；不过，问题在于，它模糊了架构与详细设计之间的界线。简而言之，架构是设计的宏观部分，例如，模块及模块之间的连接方式，至于详细设计，则涵盖了设计的其他方面。

然而，有关架构细节的大量示例说明架构并非仅限于系统的宏观层面。最初的Java Bean规格说明书就为公开Bean的属性规定了命名规范，隐藏其后的设计思想就是通过反射将方法转换为公开的属性，例如，将方法getTargetVelocity转换为公开的属性TargetVelocity。尽管方法的命名规范是相当底层的设计决策，但在架构层面，它对于Java Bean却意义重大。与之类似，有的架构可能会禁用线程，例如，要求方法在100毫秒内执行完毕，要求运算可以被分解为多个作业(job)，抑或其他深深植根于代码中的设计细节。

由此得出一个不尽如人意的结论，即架构关注于设计的宏观部分，但有时却并非如此。根据如此定义，谁又能决定哪些内容才属于架构呢？或许房屋及摩天大厦的设计者可以把架构与设计之间的区别解释明白。与软件相似，房屋的设计者仍然需要架构设计与详细设计；然而，软件开发的历史才不过半个世纪，而房屋建造的历史却已有悠悠千载。

我的兄弟就是建造摩天大厦的，他告诉我，在他的领域里，建筑设计师通常会指定一些低级别的细节，而将其余细节留给建筑公司来决定。判断设计细节是否属于架构范畴，就是看这些细节是否会直接影响建筑物的整体质量，例如，建筑物的水密性(watertightness)、美学观感及可施工性。是，则属于；反之，则不属于。在我兄弟的最近的一份工作中，建筑设计师坚持己见，要求窗户之间的间隔必须足够小，因为这一细节决定了建筑设计师对建筑物外观的设计意图。

意图　要从诸多细节中分辨出属于架构的部分，要旨在于把握其意图：架构师的某些高层意图或决策会影响到低层的细节，就好像传递意图的链条一般。尽管大多数细节对任何合理的实现保持开放，但对某些细节却有所限制，并可以沿着意图链条回溯到设计者的高层意图。一份有关架构的详细说明可能是宏观与微观细节的混合物，它甚至可能是不完整的，并未勾勒出每个高层模块的轮廓，却限制方法的命名规范(例如，Java Beans)。

传递架构意图链条的想法存在瑕疵，因为它难以准确表达“高层意图或决策”这一概念；并且某些系统虽然拥有架构层面的细节内容，却非有意为之。不过，当无法区分架构与设计，或者基于某位架构师的突发奇想得到的内容时，这一想法仍然大有裨益。它看起来吻合各种针对真实系统确定的架构决策，包括高层与低层决策的混合。正如设计摩天大厦，只要细节关乎系统的整体质量，它就可能属于架构层面的内容。