1.2.3 多种架构维度

没有单独的系统。世界是一个整体。系统的边界取决于讨论的主题。

——Donella H. Meadows

古希腊物理学家逐渐学会了基于不动点来分析宇宙，最终形成了经典力学（https://oreil.ly/jHoLH）。然而在20世纪初，更精细的仪器和更复杂的现象使得该定义向相对论逐渐转化。科学家意识到他们曾以为彼此孤立的现象实际上是互相作用的。自20世纪90年代以来，受此启发的架构师更多地将架构视为多维度的。而持续交付将运维也囊括了进来。然而，软件架构师往往只关注技术架构（即软件部分如何组织在一起），但那只是软件项目的一个维度。如果架构师想要构建可演进的架构，那么必须考虑系统中会被变更影响的所有的内连部分。如同我们从物理学家那里学到的，万物都是相关联的，架构师必须知道软件项目是多维的。

为了构建可以演进的软件系统，架构师不能只考虑技术架构。例如，如果项目包含关系型数据库，那么数据库实体之间的结构和关系也会随时间演变。类似地，架构师不希望系统演进的过程中暴露安全漏洞。这些都是不同系统维度的例子——架构的各部分彼此之间通常相对独立。部分维度常常被我们称为架构关注点（即前文提到的“特性”），但维度的含义要更广泛些，包含了传统意义上的技术架构以外的许多东西。每个项目都有一些维度是架构师在演进架构时必须考虑的。下面是一些影响现代软件架构可演进性的常见维度：

技术

架构中的实现部分：框架、依赖库和实现语言。

数据

数据库模式、表结构、优化计划等。通常由数据库管理员处理这部分架构。

安全

定义安全策略、指导方针，并确定发现缺陷的工具。

运维和系统

关注架构如何映射到现有的物理或虚拟基础设施：服务器、机器集群、交换机、云资源等。

上述的每个视角都可以构成一个架构维度——一种旨在支持特定视角的划分方式。架构维度的概念涵盖了传统的架构特征，以及任何参与软件构建的角色。它们中的每一个都构成了一种架构视角，而我们希望即使发生问题演变和环境变更，这些棱角仍得以留存。

当架构师以架构维度的方式思考问题，它就提供了一种机制，通过评估每个重要的架构维度响应变更的方式，架构师可以分析不同架构的可演进性。随着系统与相互冲突的关注点（可伸缩性、安全、分布式、事务等）交织得愈发紧密，架构师必须跟踪更多的维度。只有结合所有重要维度来思考系统演进，才能构建出可演进的系统。

项目的整个架构范围不仅包含软件需求，还包含其他维度。我们可以使用适应度函数来保护这些特性不被架构和生态系统演进、时间推移所改变，如图1-2所示。

图1-2：架构包含需求及其他维度，它们都可以用适应度函数保护

在图1-2中，架构师确定将可审计性、数据、安全、性能、合法性以及可伸缩性作为关键架构特征。随着业务需求的不断变化，每个架构特征都可以通过适应度函数来保护其完整性。

在关注架构整体的重要性的同时，我们也意识到，架构演进大多需要关注技术架构模式，以及诸如耦合和内聚这样的主题。我们将在第5章讨论技术架构上的耦合如何影响演进，并在第6章谈及数据耦合的影响。

耦合不仅适用于软件项目中的结构元素。很多软件公司近来惊奇地发现团队结构对架构也有影响。我们会讨论软件中的各种耦合，也会在第9章讨论团队结构带来的影响。

演进式架构有助于回答致力于现代软件开发生态系统的架构师的两个常见问题：长期规划如何应对层出不穷的变化？架构构建完成后，如何防止其随时间推移而退化？让我们进一步探索这两个问题。