本文探讨什么是「软件架构」，并对其下个定义！
决策or组成？
如果你去google一下「什么是软件架构」，你会看到各种各样的定义！不过大致可分为「决策」论和「组成」论！
其中一个比较著名的「决策」论的定义是Booch,Rumbaugh和Jacobson于1999年提出的：
而「组成」论中最受推崇的是SEI(Software Engineering Institute)的Len Bass等人提出的定义：
Fielding博士在他的博士论文《Architectural Styles and the Design of Network-based Software Architectures》中对软件架构的定义是这样的：
这其实也是「组成论」！不过这里说的是系统运行时的快照！
为什么会出现这样的分歧呢？我觉得主要问题在每个人对「架构」这个词的理解！
我先来问你一个问题，你觉得「架构」这个词是名词还是动词？或者说「架构」是一个过程，还是一个结果？
「架构」对应英文单词「Architecture」，在英文里Architecture是个名词，表示结构。但实际上结构只是架构的产物，如何得到这个结构呢？是通过架构师的一个个决策得到的。所以，「架构」包含了过程和结果！
如果你去搜一下「架构」这个词的解释，你就会发现，在中文里，「架构」这个词有两层含义（来自百度词典）：
- 一是间架结构
- 二是构筑，建造
那么，「架构」是决策还是组成呢？
Wiki上对Architecture给出了一个比较好的定义：
翻译过来就是：
但是我觉得这个定义还不够，还缺少了一个关键内容，就是「约束」！
下个定义
我个人对架构的理解是：架构是特定约束下决策的结果，并且这是一个循环递进的过程。
这句话包含了三个关键词：特定约束、决策、结果。这三个词都是中性词。特别是第三个词，由于决策的不同，得到的结果也就不同，可能是「成果」，也可能是「后果」！下面来一个个具体解释。
- 特定约束
我们都学过阅读理解，老师在教阅读理解的时候，会提到一个词，叫「语境」！比如下面这个段子！
这里的「意思」在不同的语境下有不同的含义。语境就是上下文，也就是我们软件行业常说的Context！Context不同，得到的结果也就不同！
其实任何行为、言语、结论都有一个Context为前提！只是在不同的情况下我们对这个Context的叫法不同！比如：
这句话在欧几里得几何这个Context下是成立的！但是在非欧几何这个Context下就是不成立的！在数学里，这个Context可以称为是「限定条件」！
同样的牛顿力学定律，在普通场景下是成立的！但是在量子力学下是不成立的！在物理里，这个Context可以称为「环境」！
在架构里也一样，淘宝的架构可能在其它情况下并不适用，因为Context不同！这里的Context就称为「约束」！
而且这个「约束」必须是「特定约束」，不能是「泛约束」！比如说，「我要造个房子」，这个约束就是个「泛约束」！是没办法执行的！（下节通过例子来详细说明）
- 决策
决策是一个过程！实际上就是选择！选择技术、结构、通信方式等内容，去符合「特定约束」！
在决策时，实际上无形中又加入了一个约束：人的约束！做决策的人的认知又约束了决策本身！比如某个架构师只知道分层架构，那么他无论在哪种Context下都只有分层架构这一个选择！
- 结果
是决策的最终产物：可能是运行良好、满足需求的系统。也可能是一堆文档。或者是满嘴的跑火车！
如果这个结果是五视图、组件、接口、子系统、及其之间的关系，那么这个架构就是软件架构！
如果这个结果是建筑图纸、钢筋水泥、高楼大厦，那么这个架构就是建筑架构！
如果这个结果是事业成功、家庭美满，那么这个架构就是人生架构，也叫人生规划！
举个例子
以上面「我要造个房子」为例，来详细解释「架构是特定约束下决策的结果」！
上面已经说了「我要造个房子」是个泛约束，是无法满足的！因为它有很多可能性选择，且很多选择是互斥的！例如：
- 房子造在哪里？城市、乡村、山顶、海边、南北极......
- 要造成什么样子？大平层、楼房、草房、城堡......
- 要使用什么材料？水泥、玻璃、木头、竹子......
- ......
这里实际就是需求收集阶段，需要和客户沟通，挖出具体的客户需求！
假设客户最终决定：想在海边建个房子，适合两个人住，每半年过来度假一周左右，希望能方便的看到海、还有日出，预计支出不超过XX元！这就是功能性需求！
通过上面的功能性需求，你需要挖出非功能性需求：
- 海边风大、潮湿。如何防风？防潮？
- 海潮声音大，是否需要做好隔音？避免影响睡眠？
- 希望能看到海和日出，使用玻璃是否合适？需要什么样的玻璃？
- 价格是否超出预算？
- .....
完善的需求（功能性、非功能性），实际就是架构的「特定约束」！而对上面这些问题的选择，就是「决策」！
- 为了防风，地基要打深一点；要使用防潮材料
- 墙壁需要加厚，使用隔音门和窗户
- 面朝大海的墙使用强化加厚玻璃墙
- 选择价格内的材料
- ......
这些决策确定后，需要告诉工人如何建造！需要相关的设计图，对不同的人需要不同的图！比如，对建造工人就是整体结构说明图，水电工就是水电线路图！这些图纸就是你决策的部分结果。
整个过程是个循环递进的过程！比如：你为了解决客户方便看海的问题，先选择了开一个较大的窗户的方案！但是客户觉得不够大！你决定直接把整面墙都使用玻璃来建造，客户很满意，但是承重、防风等问题如何解决？你最终决定通过使用强化的加厚玻璃来解决这个问题！
最终交付给客户的房子才是你架构的最终成果！
免责申明：我不懂造房子，以上言论都是胡诌的，你理解意思就行了！
纵向深入
最近订阅了李运华的《从0开始学架构》，他对架构的理解是：软件架构指软件系统的顶层结构！我觉得这个定义太过宽泛了，且只是定义了「结构」而没有说明「过程」！不过，这间接说明了架构和设计的关系！架构是顶层设计！
从操作层面做决策：用户从哪里进入、页面应该跳转到哪里、应该输入哪些信息.....这就是流程设计！
从代码层面决策，代码该怎么写：模块如何组织、包如何组织、类如何组织、方法如何组织......这就是代码设计！
从系统整体层面决策：子系统如何组织、组件如何组织、接口如何设计......这就是架构设计！
横向扩展
好像架构思维是个比较通用的思维方式！读书，演讲，写作.....都是这样！
读书，你需要先了解这本书是讲关于什么的？计算机、哲学、心理学.....以及具体是讲的哪个方面？这是约束！然后你需要问自己，自己是否需要了解这些内容？是否需要读这本书？这就是决策！如果需要读，那么再进一步，这本书的整体结构是什么样子的？我该怎么读？这个章节是讲什么的？我是否需要读？我是否同意作者的结论？如果同意，我为什么同意？如果不同意，我为什么不同意？我有什么自己的观点？最终的成果就是我对这本书的个人理解！
演讲，你需要先了解你是对谁进行演讲的？要讲什么？听众的水平如何？听众的水平以及演讲的内容就是你演讲的约束！然后你需要考虑如何进行演讲？演讲的整体结构该怎么组织？该用什么样的语言？是否该讲个笑话？各个小节里的内功如何组织？这里是否需要设置问题？这里是否可能会有人提出问题？会提出什么样的问题？我该如何回答？这些是决策！最终，做出来的演讲，就是我这次演讲的成果！
写作和演讲比较类似，少了一些互动。就不再赘述了！
做个小结
本文梳理了我对架构的理解：架构是特定约束下决策的结果，并且这是一个循环递进的过程。并通过例子来解释我为什么这么理解！