收藏 | 架构设计的基础认知

1.1 架构的定义

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

1.2 架构、框架、组件、模块、系统的本质

 •  架构是顶层设计； 

 •  框架是面向编程或配置的半成品； 

 •  组件是从技术维度上的复用； 

 •  模块是从业务维度上职责的划分； 

 •  系统是相互协同可运行的实体。

1.3 架构与框架的区别？

1.软件架构：软件系统的“基础结构”，创造这些基础结构的准则，以及对这些结构的描述。 

2.软件框架：为了实现某个业界标准或完成特定基本任务的软件组件规范，也指为了实现某个软件组件规范时，提供规范所要求之基础功能的软件产品。

架构关注的是“结构”，框架关注的是“规范”。

2.1 背景探寻

只有规模较大的软件系统才面临软件架构相关的问题。 
例如： 
1）系统规模庞大、内部耦合严重，开发效率低； 
2）系统耦合严重，牵一发动全身，后续修改和扩展困难； 
3）系统逻辑复杂，容易出问题，出问题后很难排查和修复。

2.2 设计的重要性

 •  布鲁克斯发表《人月神话》三十年后，又写了《设计原本》。他认为一个成功的软件项目的最重要的因素就是设计。 

 •  架构师、设计师需要在业务需求和IT技术中寻找一个平衡点。而对这个平衡点的把握，就是架构设计中的取舍问题。 

 •  这种取舍的决策大部分是靠技术（新工具、方法论、管理模式的提升），但一定程度上也依赖于架构师的“艺术”（无法量化，需要权衡）。
3.1 架构设计的主要目的

为了解决软件系统功能复杂度带来的问题。

3.2 架构设计的认知

1.认知1：需求驱动架构。 
通过熟悉和理解需求，识别系统复杂性所在的地方，然后针对这些复杂点进行架构设计。

2.认知2：架构设计并不是要面面俱到。 
不需要每个架构都具备高性能、高可用、高扩展性等特点，而是要识别出复杂点，然后有针对的解决问题。

3.认知3：架构是为了应对软件复杂度而提出的解决方案。 
理解每个架构方案背后所需要解决的复杂点，才能对比自己业务复杂点，参考复杂点相似的方案。

架构即（重要）决策，是在一个有约束的盒子里去求解出或接近求解出最合适的解。 
有约束的盒子=团队经验、成本、资源、进度、业务所处的阶段等编织、掺杂在一起的综合体（人，财，物，时间）。

架构无优劣，但是存在恰当的架构用在合适的软件系统中，而这些都是决策的结果。

 

 •  最大收获：认清了架构设计的主要目的是——为了解决软件系统功能复杂度带来的问题。 

 •  反过来说，如果要对一个新产品、项目开发进行架构设计，先需要结合需求、排出软件系统功能复杂度， 

 •  针对软件系统功能复杂度最高的部分进行架构选型、设计。