什么是架构？

第66篇

极客时间《从0开始学架构》课程笔记。

要理解什么是架构，需要先搞明白系统、子系统、组件、模块的定义，再区分出框架，然后才能真的理解什么是架构（设计）。

系统与子系统

系统无处不在。
地球是系统，太阳系也是系统；手机是系统，运行在手机里的APP是系统；电脑是系统，运行在电脑里的软件程序也是系统；浏览器是系统，打开某个网站也是系统。
似乎明白系统是什么，又似乎无法准确定义它。
维基百科上定义如下：

系统（system）:泛指由一群有关联的个体组成，根据某种规则运作，能完成个别元件不能单独完成的工作的群体。系统分为自然系统与人为系统两大类。

关键词： 个体关联、运作规则、群体工作

关联代表多个个体，不是一个。规则代表有指定要求和顺序，不是随意组合。群体工作则突出能力的变化，不是个体的能力累加，而是形成新能力：『系统能力』。

子系统定义与系统一样，只是突出表达是一个大系统的组成部分，大系统由多个子系统组成。
系统=子系统A+子系统B……+子系统N

组件与模块

在平时工作中，这两个概念一直没区分，仅仅是哪个用着顺手就用哪个，基本认为是一个相同的概念了。
但实际上，两个概念是有区别的，但不是正确与错误的那种区别，而是描述角度的差异而已。

模块（Module）：是一套一致而互相有紧密关连的软件组织。它分别包含了程序和数据结构两部分。
组件（Component）：自包含的、可编程的、可重用的、与语言无关的软件单元，软件组件可以很容易被用于组装应用程序中。

1、模块和组件都是系统的组成部分，只是从不同的角度拆分系统而已。
2、从逻辑的角度来拆分系统后，得到的单元就是“模块”；划分模块的主要目的是职责分离；模块偏业务。
3、从物理的角度来拆分系统后，得到的单元就是“组件”；划分组件的主要目的是单元复用；组件偏技术。
4、模块是对系统进行横向拆分，为了便于分工协作；而组件是纵向切分，站在成本角度，目的是为了复用，具备独立可替换特点。

框架与架构

软件框架（Software Framework），通常指的是为了实现某个业界标准或完成特定基本任务的软件组件规范，也指为了实现某个软件组件规范时，提供规范所要求之基础功能的软件产品。框架的功能类似于基础设施，与具体的软件应用无关，但是提供并实现最为基础的软件架构和体系。软件开发者通常依据特定的框架实现更为复杂的商业运用和业务逻辑。这样的软件应用可以在支持同一种框架的软件系统中运行。

软件架构（ Software Architecture）是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。软件架构师定义和设计软件的模块化，模块之间的交互，用户界面风格，对外接口方法，创新的设计特性，以及高层事物的对象操作、逻辑和流程。

1、框架是一套规范或者规则（思想），或者提供基础功能的产品。
2、架构是结构与组件的抽象描述，是系统整体的顶层设计，用来处理软件高层次结构的设计和实施。
3、框架关注『规范』，架构关注『结构』。
4、同一个框架可以用在不同系统的软件架构中。
5、同一个系统的架构可以通过不同角度进行描述，如『4+1视图』

『4+1 视图』：
逻辑视图（Logical View），设计的对象模型（使用面向对象的设计方法时）。
过程视图（Process View），捕捉设计的并发和同步特征。
物理视图（Physical View），描述了软件到硬件的映射，反映了分布式特性。
开发视图（Development View），描述了在开发环境中软件的静态组织结构。
场景视图：由一些用例 （use cases）或场景(scenarios)来说明。

架构的定义

软件架构指软件系统的顶层结构。

1、个体=子系统或模块或组件；系统 = 一群关联个体根据规则运行
2、架构需要明确：个体包含哪些『个体』、个体运作和协作的规则
3、顶层结构突出『顶层』，区分系统和子系统，关注整体而不是个体

延伸阅读

软件框架
软件架构
软件架构 "4+1" 视图模型
运用RUP 4+1视图方法进行软件架构设计