软件架构设计本质

1、机器语言：难读，难写。
2、汇编语言：不能夸CPU，多环境需要多个编写版本。
3、高级语言：好处解决跨平台。

4、两次软件危机
①、软件规模和复杂度增加，导致软件质量下降，把控难度高。
解决这一问题，提出了软件工程，结构化程序设计，思想本质是面向过程设计思想。但通过“自顶向下、逐步细化、模块化”的方法，将软件的复杂度控制在一定范围内，从而从整体上降低了软件开发的复杂度。
②、但通过“自顶向下、逐步细化、模块化”的方法，将软件的复杂度控制在一定范围内，从而从整体上降低了软件开发的复杂度。
第二次软件危机的根本原因还是 在于软件生产力远远跟不上硬件和业务的发展。
面向对象的思想开始流行起来。在一定程度上解决了软件“扩展”带来的复杂性。但事实证明，和软件工程、结构化程度设计一样，面向对象也不是银弹，而只是一种新的软件方法而已。

5、软件架构的产生

“软件架构”的出现有其历史必然性。第一次软件危机引出了“结构化编程”，创造了“模块”概念；第二次软件危机引出了“面向对象编程”，创造了“对象”概念；直到“软件架构”的产生，创造了“组件”概念。
“模块”、“对象”和“组件”本质上都是对达到一定规模的软件进行拆分，差别只是在于随着软件的复杂度不断增加，拆分的粒度越来越粗，拆分的层次越来越高。

架构指什么

对于技术人员来说，“架构”是一个再常见不过的词了。当提起“架构”这个词时，如果去深究一下：“架构”到底指什么？大部分人也许并不一定能够准确地回答。1000个人心中可能有1001种架构的含义。

那么如何才能准确的理解架构呢？理解架构首先理解三个有关系而又相似的概念，包括：系统与子系统、模块与组件、框架与架构。

1、系统与子系统
系统泛指由一群 有关联 的个体组成，根据某种 规则运作，能完成 个别元件不能单独完成的工作的群体。它的意思是“总体”、“整体”或“联盟”。子系统也是由一群有关联的个体所组成的系统，多半会是更大系统中的一部分。

2、模块与组件
从逻辑的角度来拆分系统，得到的单元就是“模块”；从物理的角度来拆分系统，得到的单元就是“组件”。划分模块的主要目的是职责分离；划分组件的主要目的是单元复用。其实，“组件”的英文“component”也可以翻译成中文的“零件”一词，“零件”更容易理解一些，“零件”是一个物理的概念，并且具备“独立且可替换”的特点。

3、框架与架构
单纯从定义的角度来看，框架关注的是“规范”，架构关注的是“结构”。框架的英文是“Framework”，架构的英文是“Architecture”。
我们经常会说，比如：“工程采用的是MVC架构”、“工程使用的是SSH框架”等。所以，第一句话是站在结构的层面来说明，第二句话是站在规范的层面来说明。

4、重新定义架构
软件架构指软件系统的顶层结构。
首先，“系统是一群关联个体组成”，这些“个体”可以是“子系统”、“模块”、“组件”等；架构需要明确系统包含哪些“个体”。
其次，系统中的个体需要“根据某种规则”运作，架构需要明确个体运作和协作的规则。

总结

架构其实就是为了应对软件系统复杂度而提出的解决方案。架构关键思维即为判断与取舍。
正如，在一个有约束的盒子里去求解或接近最合适的解。这个约束的盒子可能会包含团队经验、成本、资源、时间、业务阶段等因素掺杂在一起的综合体，针对这个综合体，分析出系统架构的复杂度，进行合适的判断与取舍，从而设计出恰当的架构用在合适的软件系统中。