什么是软件架构

本文探讨什么是「软件架构」，并对其下个定义！

决策or组成？

如果你去google一下「什么是软件架构」，你会看到各种各样的定义！不过大致可分为「决策」论和「组成」论！

其中一个比较著名的「决策」论的定义是Booch,Rumbaugh和Jacobson于1999年提出的：

架构就是一系列重要的决策，这些决策涉及软件系统的组织、组成系统的结构化元素及其接口的选择、元素之间协作时特定的行为、结构化元素和行为元素形成更大子系统的组合方式以及引导这一组织（也就是这些元素及其接口）、他们之间的协作以及组合（架构风格）。

而「组成」论中最受推崇的是SEI(Software Engineering Institute)的Len Bass等人提出的定义：

The software architecture of a program or computing system is the structure or structures of the system,which comprise software elements,the externally visible properties of those elements,and the relationships among them.

Fielding博士在他的博士论文《Architectural Styles and the Design of Network-based Software Architectures》中对软件架构的定义是这样的：

A software architecture is an abstraction of the run-time elements of a software system during some phase of its operation. A system may be composed of many levels of abstraction and many phases of operation, each with its own software architecture.
软件架构是软件系统在其操作的某个阶段的运行时的元素的抽象。一个系统可能由很多层抽象和很多个操作阶段组成,每个抽象和操作阶段都有自己的软件架构。

这其实也是「组成论」！不过这里说的是系统运行时的快照！

为什么会出现这样的分歧呢？我觉得主要问题在每个人对「架构」这个词的理解！

我先来问你一个问题，你觉得「架构」这个词是名词还是动词？或者说「架构」是一个过程，还是一个结果？

「架构」对应英文单词「Architecture」，在英文里Architecture是个名词，表示结构。但实际上结构只是架构的产物，如何得到这个结构呢？是通过架构师的一个个决策得到的。所以，「架构」包含了过程和结果！

如果你去搜一下「架构」这个词的解释，你就会发现，在中文里，「架构」这个词有两层含义（来自百度词典）：

一是间架结构
二是构筑，建造

那么，「架构」是决策还是组成呢？

Wiki上对Architecture给出了一个比较好的定义：

Architecture is both the process and the product of planning, designing, and constructing buildings or any other structures。

翻译过来就是：

架构是规划、设计、构建的过程及最终成果

但是我觉得这个定义还不够，还缺少了一个关键内容，就是「约束」！

下个定义

我个人对架构的理解是：架构是特定约束下决策的结果，并且这是一个循环递进的过程。

这句话包含了三个关键词：特定约束、决策、结果。这三个词都是中性词。特别是第三个词，由于决策的不同，得到的结果也就不同，可能是「成果」，也可能是「后果」！下面来一个个具体解释。

特定约束

我们都学过阅读理解，老师在教阅读理解的时候，会提到一个词，叫「语境」！比如下面这个段子！

领导：你这是什么意思？
小明：没什么意思，意思意思。
领导：你这就不够意思了。
小明：小意思，小意思。
领导：你这人真有意思。
小明：其实也没有别的意思。
领导：那我就不好意思了。
小明：是我不好意思。
提问：以上“意思”分别是什么意思？

这里的「意思」在不同的语境下有不同的含义。语境就是上下文，也就是我们软件行业常说的Context！Context不同，得到的结果也就不同！

其实任何行为、言语、结论都有一个Context为前提！只是在不同的情况下我们对这个Context的叫法不同！比如：

直角三角形的两直角的平方等于斜边的平方

这句话在欧几里得几何这个Context下是成立的！但是在非欧几何这个Context下就是不成立的！在数学里，这个Context可以称为是「限定条件」！

同样的牛顿力学定律，在普通场景下是成立的！但是在量子力学下是不成立的！在物理里，这个Context可以称为「环境」！

在架构里也一样，淘宝的架构可能在其它情况下并不适用，因为Context不同！这里的Context就称为「约束」！

而且这个「约束」必须是「特定约束」，不能是「泛约束」！比如说，「我要造个房子」，这个约束就是个「泛约束」！是没办法执行的！（下节通过例子来详细说明）

决策

决策是一个过程！实际上就是选择！选择技术、结构、通信方式等内容，去符合「特定约束」！

在决策时，实际上无形中又加入了一个约束：人的约束！做决策的人的认知又约束了决策本身！比如某个架构师只知道分层架构，那么他无论在哪种Context下都只有分层架构这一个选择！

结果

是决策的最终产物：可能是运行良好、满足需求的系统。也可能是一堆文档。或者是满嘴的跑火车！

如果这个结果是五视图、组件、接口、子系统、及其之间的关系，那么这个架构就是软件架构！

如果这个结果是建筑图纸、钢筋水泥、高楼大厦，那么这个架构就是建筑架构！

如果这个结果是事业成功、家庭美满，那么这个架构就是人生架构，也叫人生规划！

举个例子

以上面「我要造个房子」为例，来详细解释「架构是特定约束下决策的结果」！

上面已经说了「我要造个房子」是个泛约束，是无法满足的！因为它有很多可能性选择，且很多选择是互斥的！例如：

房子造在哪里？城市、乡村、山顶、海边、南北极......
要造成什么样子？大平层、楼房、草房、城堡......
要使用什么材料？水泥、玻璃、木头、竹子......
......

这里实际就是需求收集阶段，需要和客户沟通，挖出具体的客户需求！

假设客户最终决定：想在海边建个房子，适合两个人住，每半年过来度假一周左右，希望能方便的看到海、还有日出，预计支出不超过XX元！这就是功能性需求！

通过上面的功能性需求，你需要挖出非功能性需求：

海边风大、潮湿。如何防风？防潮？
海潮声音大，是否需要做好隔音？避免影响睡眠？
希望能看到海和日出，使用玻璃是否合适？需要什么样的玻璃？
价格是否超出预算？
.....

完善的需求（功能性、非功能性），实际就是架构的「特定约束」！而对上面这些问题的选择，就是「决策」！

为了防风，地基要打深一点；要使用防潮材料
墙壁需要加厚，使用隔音门和窗户
面朝大海的墙使用强化加厚玻璃墙
选择价格内的材料
......

这些决策确定后，需要告诉工人如何建造！需要相关的设计图，对不同的人需要不同的图！比如，对建造工人就是整体结构说明图，水电工就是水电线路图！这些图纸就是你决策的部分结果。

整个过程是个循环递进的过程！比如：你为了解决客户方便看海的问题，先选择了开一个较大的窗户的方案！但是客户觉得不够大！你决定直接把整面墙都使用玻璃来建造，客户很满意，但是承重、防风等问题如何解决？你最终决定通过使用强化的加厚玻璃来解决这个问题！

最终交付给客户的房子才是你架构的最终成果！

免责申明：我不懂造房子，以上言论都是胡诌的，你理解意思就行了！

纵向深入

最近订阅了李运华的《从0开始学架构》，他对架构的理解是：软件架构指软件系统的顶层结构！我觉得这个定义太过宽泛了，且只是定义了「结构」而没有说明「过程」！不过，这间接说明了架构和设计的关系！架构是顶层设计！

从操作层面做决策：用户从哪里进入、页面应该跳转到哪里、应该输入哪些信息.....这就是流程设计！

从代码层面决策，代码该怎么写：模块如何组织、包如何组织、类如何组织、方法如何组织......这就是代码设计！

从系统整体层面决策：子系统如何组织、组件如何组织、接口如何设计......这就是架构设计！

横向扩展

好像架构思维是个比较通用的思维方式！读书，演讲，写作.....都是这样！

读书，你需要先了解这本书是讲关于什么的？计算机、哲学、心理学.....以及具体是讲的哪个方面？这是约束！然后你需要问自己，自己是否需要了解这些内容？是否需要读这本书？这就是决策！如果需要读，那么再进一步，这本书的整体结构是什么样子的？我该怎么读？这个章节是讲什么的？我是否需要读？我是否同意作者的结论？如果同意，我为什么同意？如果不同意，我为什么不同意？我有什么自己的观点？最终的成果就是我对这本书的个人理解！

演讲，你需要先了解你是对谁进行演讲的？要讲什么？听众的水平如何？听众的水平以及演讲的内容就是你演讲的约束！然后你需要考虑如何进行演讲？演讲的整体结构该怎么组织？该用什么样的语言？是否该讲个笑话？各个小节里的内功如何组织？这里是否需要设置问题？这里是否可能会有人提出问题？会提出什么样的问题？我该如何回答？这些是决策！最终，做出来的演讲，就是我这次演讲的成果！

写作和演讲比较类似，少了一些互动。就不再赘述了！