[架构之路-92]：《软件架构设计：程序员向架构师转型必备》-2-解析软件架构的概念

Posted 2023-02-16 文火冰糖的硅基工坊

前言：

什么是软件架构？不同的人，有不同的答案。因为架构无处不再，架构又有不同层面。

很多人都给架构定义，不同的人，对架构有不同的理解，很难统一。

本文是按照作者个人的理解，来展现一个程序员如何向架构师演进的路径。

第2章 解析软件架构概念

程序员要转向架构的第一道门槛就是：什么是架构？在众多定义中，如何立足自身的实际情况和起点，转型软件架构师？

2.1 软件架构概念分类

这个派别的思想源于建筑行业的架构，也源于架构这个单词本身，该派别人为，软件是一个系统，任何系统都是有组件、子系统、模块等组成的，通过分解还原一个软件系统，通过划分组件、子系统、模块来构建一个新的系统。

组成派是站在目标系统的角度，以目标系统为目标和中心。

决策派站在人的角度看目标系统，他们认为目标系统是人意愿的体现，是人的决策的体现，展现的是一种人对目标系统的一个愿景和规划。除了看得见的功能性需求，还包括了看不见的非功能性需求。

备注：

（1）组成派=》站在目标系统的角度看，架构是名词，是目标系统。

（2）决策派=》站在需求者的角度看，架构是动词，是愿景，是决策过程。

（3）程序员 =》站在程序员的角度看，架构是名词，是实现后的样子。

站在程序员的角度，其实可以不用陷入到概念之争中，而是从实践出发，立足行为，先依葫芦画瓢，等进入高阶阶段后，再思考如何进行概念化和思想总结。

（4）业务需求：业务的角度看，这个系统如何解决业务需求，如何赚钱？

（5）用户需求：用户的角度看，从使用者的角度看，目标系统是如何使用的？

（6）功能需求：程序的角度看，你到底希望“我”的软件怎么做？

2.2 核心思想解析

2.2.1 关注软件系统的组成部分的分割与交互

任何系统，都是由各个子系统组成，子系统与子系统之间，子系统与外界一定存在一定的交互，没有交互的子系统是孤岛，注定没有存在的价值。组件本质是就是子系统。

2.2.2 架构是自顶向下逐步分层的树型决策

.......................................

2.2.3 架构无处不在

备注：

虽然架构无处不在，但架构师这个专门的角色并非无处不在，在很多创业型公司或小型的软件系统中，是不需要软件架构师这个专门的角色的，架构的工作被分摊到CTO或程序员身上了。

2.3 工程实践

2.3.1 基于手头上的实际代码理解架构

一方面，程序员能够跳出代码的细节，抽象出系统的架构。

另一方面，架构是不能脱离手头上的软件代码，重构架构，架构师的架构要落地，要有支撑点，在一个已有的系统上，架构是构建在代码之上的，是已有代码的抽象；在一个新系统中，代码是蓝图，是代码的蓝图，代码是按照架构的方式构建软件系统的。

一个好的系统，是架构师与程序员的通力合作和相互信任，程序员相信架构师的架构能力，架构师相信程序员的编程能力。

2.3.2 架构是类的抽象定义吗？

架构师如何只定义类的抽象定义，程序员只按照抽象定义去实现，就不需要架构师这个角色了，优秀的程序来充当就可以了。

架构师做能够程序员的基础上做增量工作：

• 在更高层次上抽象系统，而不是类级别，如业务需求层面、用户层面和逻辑功能层面进行抽象，而类是实现层面的抽象。

• 除了功能性需求，还要关注非功能性需求，确保架构的系统满足未来的需要，而不是仅仅当下的需要

• 架构师要引领未来的方向，软件代码是满足业务需求的，软件架构要能够为当下的业务服务，同时也能适应未来的业务需求，只能需要有演进线路。

2.3.3 架构师不是需求工程师

架构师不仅仅要提软件的功能和非功能需要，还需要给出具体的技术方案，这是架构师与需求工程师最具备价值的地方。比如采用什么样的设计模式，技术方案选型等等。

2.4.4 不同派别不过是站的角度不同

感悟：

• 架构的思想，不仅仅适合软件系统，也适合任何系统，包括国家、企业、公司、组织、团队。

• 架构不仅仅是看得见的功能性需要，也包括看不见的非功能性需要，如稳定性、可靠性、安全性、伸缩性等。

• 架构是不同层面上的抽象，是业务目标的一步一步实现过程：业务需求层=》用户层=》功能与非功能层=》代码设计=》代码