从架构师角度看架构

软件架构的四大核心维度

根据电气和电子工程师协会（IEEE）的定义，软件架构本质上描述了一个软件系统的基本组织结构。具体而言，软件架构由以下四个核心部分组成：

1. 组成系统的组件（Components） 组件是系统模块化的一部分，从设计角度来看，其本质是一系列功能集的封装体。这是一种逻辑概念上的封装，而非物理上的存在。

◦ 系统的本质：系统本身就是由一系列组件集合而成的，这些组件被组织起来以完成一系列功能。

◦ 概念的统一性：在本质上，“组件”、“模块”、“子系统”和“系统”是趋同的，它们都是对功能集的封装，区别仅在于封装功能的数量多少或粒度大小。

2. 组件之间的关系（Relationships between Components） 这描述了系统内部各个组件之间是否存在联系以及如何交互。

◦ 常见的关系包括依赖关系（一个组件调用或使用另一个组件）、调用关系以及扩展关系（对现有功能进行扩展）等。

3. 组件与环境之间的关系（Relationships with the Environment） 环境（或称上下文）是指软件系统之外、会对系统的开发和运行造成影响的外部因素。

◦ 环境的类型：包括配置设置（如内存大小、连接池参数）、政策法规（如财务、银行行业的法律要求）以及软硬件部署环境（如Windows/Linux操作系统、云端、硬件规格）。

◦ 架构需要处理组件如何适应或符合这些外部环境的要求（例如税务组件必须符合税法规则）。

4. 指导设计和演化的原则（Principles guiding Design and Evolution） 架构包含指导上述内容进行设计和后续演化的原则。

◦ 软件设计不是一蹴而就的，需要不断修改、完善和调整。架构设计必须考虑系统的可扩展性、可维护性以及应对未来变化的能力，而不仅仅是当下的完美状态。

从设计角度来看，系统中的“组件”（Component）并非物理实体，而是一个高度抽象的逻辑概念。以下是基于架构视角的详细定义及其本质解析：

1. 核心定义：功能集的封装体 从设计层面理解，组件的本质是一系列功能集的封装体。

• 功能组合：一个软件系统可能包含成百上千个功能点（例如功能1至功能100）。架构设计将这些功能按照特定的方式进行组合，将一组相关的功能（例如功能1至功能10）“打包”在一起，这个包就是组件,。

• 逻辑属性：组件主要是一个逻辑概念上的封装，而非物理存在的实体。它是为了在设计上将系统划分为更易于管理的模块化部分。

2. 组件与系统的关系：全集与子集 系统本身可以被理解为一个巨大的“组件集”。系统是为了完成一系列功能而组织起来的组件集合。

• 从宏观角度看，系统是由一个个组件构成的；

• 从微观角度看，每个组件内部又封装了具体的功能实现。

3. 概念的统一性：本质趋同，粒度不同 在架构设计中，组件（Component）、模块（Module）、子系统（Subsystem）和系统（System）趋同的。

• 共同本质：它们全部都是“一系列功能集的封装体”,。

• 区别在于“大小”：它们的主要区别在于封装功能的数量多少（即粒度大小）。在逻辑划分上，通常认为： 组件 < 模快 < 子系统 < 系统 这只是逻辑上为了区分不同层级而人为设定的界限，实际上它们都是对功能的封装。

在架构定义中，“环境”（也被称为上下文）是指所有处于软件系统之外，但会对系统的开发和运行造成影响的因素。

这些外部影响因素具体可以分为以下三类：

1. 系统运行配置 (Settings) 这是指对软件运行时的参数设置，直接影响系统的性能和行为。

• 具体案例：包括启动系统时设置的内存使用大小、连接池的数量（如最大值、最小值）等参数。

2. 政策与法规 (Policies and Regulations) 这是指软件必须遵守的非技术性外部规则，尤其在特定行业软件中至关重要。

• 具体案例：在开发财务、银行或税务相关软件时，系统必须符合国家的政策法规要求。

• 架构影响：这种环境因素会直接决定组件内部的逻辑。例如，一个税务计算组件（Component），其内部规则必须依据外部的税法（Environment）来编写，这就是典型的“组件与环境之间的关系”。

3. 软硬件部署环境 (Software/Hardware Environment) 这是指软件最终落地运行的底层基础设施。

• 软件环境：指目标操作系统（如 Windows、Linux）或部署平台（如云端）。

• 硬件环境：指运行该系统所需的硬件规格要求

软件架构中的“演化原则”主要基于一个核心认知：软件设计并非一蹴而就的，而是一个持续发展的过程。

具体而言，演化原则指引了以下几类关键的设计行为和考量：

1. 接受持续的修改与完善 架构设计不应被视为一次性完成的“完美作品”。演化原则指导架构师认识到，系统在构建后需要不断地进行修改、完善和调整。这意味着架构在初期设计时，就不能把结构写死，而要为后续的修修补补留出空间。

2. 预判未来的变化（Future-proofing） 在做架构设计时，必须将“演化因素”纳入考量范围。架构师不仅要解决当下的问题，还需要思考系统在未来如何应对变化。具体指引的行为包括：

• 规划可扩展性（Extensibility）： 设计时要考虑当业务增长或功能增加时，系统该如何通过扩展来承载，而不是推倒重来。

• 规划可维护性（Maintainability）： 考虑系统在长期运行中“今后怎么维护”，确保代码和结构易于修复和管理。

• 应对变化的策略： 提前思考“怎么变化”，即当外部环境或需求改变时，系统架构应如何灵活调整。