精读《从零开始做架构》 _架构

架构定义什么是架构
一直以来，在软件行业，对于什么是架构，都有很多的争论，每个人都有自己的理解。为了准确的理解架构，我们将和架构有关系而且相似的几个概念进行梳理：
系统（system）:泛指由一群有关联的个体组成，根据某种规则运作，能完成个别元件不能单独完成的工作的群体。系统分为自然系统与人为系统两大类。
模块（Module）：是一套一致而互相有紧密关连的软件组织。它分别包含了程序和数据结构两部分。
组件（Component）：自包含的、可编程的、可重用的、与语言无关的软件单元，软件组件可以很容易被用于组装应用程序中。
软件框架（Software Framework），通常指的是为了实现某个业界标准或完成特定基本任务的软件组件规范，也指为了实现某个软件组件规范时，提供规范所要求之基础功能的软件产品。
维基百科对于软件架构的定义：软件架构（ Software Architecture）是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。

我比较认可的软件架构定义如下：软件架构定义了软件有哪些组件，模块，框架组成，以及他们是怎么交互了连通，体现了软件的其他非功能特性，例如扩展性，可维护性。

架构目的从这个定义上看，也不是很清晰。为了讲清楚这个问题，我们先来看看为什么会产生架构。从软件开发进化的历史，探索一下软件架构出现的历史背景。
机器语言（1940 年之前）：直接使用二进制码 0 和 1 来表示机器可以识别的指令和数据，主要问题是三难：太难写、太难读、太难改！
汇编语言（20 世纪 40 年代）：为了解决机器语言编写、阅读、修改复杂的问题，汇编语言应运而生。但是本身编写复杂,同时还要考虑不同 CPU 的汇编指令和结构是不同的。
高级语言（20 世纪 50 年代）：这些语言让程序员不需要关注机器底层的低级结构和逻辑，而只要关注具体的问题和业务即可。
第一次软件危机与结构化程序设计（20 世纪 60 年代~20 世纪 70 年代）：高级语言的出现，解放了程序员，但好景不长，随着软件的规模和复杂度的大大增加，20 世纪 60 年代中期开始爆发了第一次软件危机，典型表现有软件质量低下、项目无法如期完成、项目严重超支等，因为软件而导致的重大事故时有发生。为了解决问题，“结构化程序设计”被提了出来。结构化程序设计本质上还是一种面向过程的设计思想，但通过“自顶向下、逐步细化、模块化”的方法，将软件的复杂度控制在一定范围内，从而从整体上降低了软件开发的复杂度。
第二次软件危机与面向对象：第二次软件危机主要体现在软件的“扩展”变得非常复杂。结构化程序设计虽然能够解决（也许用“缓解”更合适）软件逻辑的复杂性，但是对于业务变化带来的软件扩展却无能为力，软件领域迫切希望找到新的银弹来解决软件危机，在这种背景下，面向对象的思想开始流行起来。虽然面向对象开始也被当作解决软件危机的银弹，但事实证明，和软件工程一样，面向对象也不是银弹，而只是一种新的软件方法而已。
软件架构：软件架构的出现有其历史必然性。到了 20 世纪 90 年代“软件架构”开始流行，创造了“组件”概念。我们可以看到，“模块”“对象”“组件”本质上都是对达到一定规模的软件进行拆分，差别只是在于随着软件的复杂度不断增加，拆分的粒度越来越粗，拆分的层次越来越高。