公司决定使用软件解决特定问题，因此它收集了该系统的需求列表。 存在多种用于执行需求收集的技术，这些技术通常由团队使用的软件开发过程定义。 但是，架构师在设计软件解决方案时必须考虑许多其他因素，如图所示。
架构师可以在定义域或业务需求方面进行协作，但是一项主要职责是定义、发现和分析软件必须执行的与领域或业务不直接相关的所有事情：架构特征。
软件架构与编码和设计的区别是什么？许多事情，包括架构师在定义架构特征方面的角色，是独立于问题域的系统方面的重要问题。许多组织使用各种术语（包括非功能性需求）来描述软件的这些功能，但是我们不喜欢该术语，因为它是贬义的。架构师创建该术语是为了将架构特征与功能需求区分开来，但是从语言的角度来看，命名非功能性的东西会带来负面影响：如何说服团队充分注意“非功能性”的东西？另一个流行的术语是质量属性，我们不喜欢它，因为它暗示事后质量评估而不是设计。我们更喜欢架构特征，因为它描述了对架构以及整个系统的成功至关重要的关注点，同时又不影响其重要性。
架构特征满足三个条件：
- 指定非领域设计注意事项
- 影响设计结构的某些方面
- 对应用程序的成功至关重要
我们定义的这些相互联系的部分如图所示。
图中所示的定义除了列出的三个修饰符外，还列出了三个组件：
指定非领域设计注意事项
在设计应用程序时，要求指定了应用程序应执行的操作；架构特征指定了成功的运维和设计标准，涉及如何实施的要求以及为何做出某些选择。例如，一个常见的重要架构特征为应用程序指定了一定的性能水平，而这通常不会出现在需求文档中。更相关的示例是：没有需求文档指出“技术债务”，但这是架构师和开发人员的常见设计考虑因素。我们在“从领域问题中提取架构特征”中深入讨论了显性和隐性特征之间的区别。-
影响设计结构的某些方面
架构师试图在项目上描述架构特征的主要原因与设计注意事项有关：此架构特征是否需要特殊的结构考虑才能成功？例如，安全实际上是每个项目的关注点，并且所有系统都必须在设计和编码过程中采取预防措施基准。但是，当架构师需要设计一些特殊的东西时，它会上升到架构特征的水平。在示例系统中，考虑两种围绕付款的情况：第三方付款处理器
如果在集成点处理付款明细，则该架构不需要特殊的结构考虑。该设计应包含标准的安全措施，例如加密和散列，但不需要特殊的结构。应用程序内付款处理
如果正在设计的应用程序必须处理付款，则架构师可以为此目的设计特定的模块、组件或服务，以从结构上隔离关键的安全问题。现在，架构特征对架构和设计都有影响。
当然，在很多情况下，即使是这两个标准也不足以做出此决定：在此决策过程中，可能会出现过去的安全事件，与第三方集成的性质以及许多其他标准。它仍然显示了架构师在确定如何为某些功能进行设计时必须考虑的一些注意事项。
- 对应用程序成功至关重要
应用程序可以支持大量的架构特征，但是不应该如此。对每个架构特征的支持增加了设计的复杂性。因此，对于架构师来说，一项关键工作在于选择最少的架构特征，而不是选择最大的可能性。
我们进一步将架构特征细分为隐式和显式架构特征。隐性需求很少出现在需求中，但它们对于项目成功是必不可少的。例如，可用性、可靠性和安全性实际上是所有应用程序的基础，但很少在设计文档中指定它们。架构师必须在分析阶段使用他们对问题领域的了解来发现这些架构特征。例如，高频交易公司可能不必在每个系统中都指定低延迟，但是该问题领域的架构师知道这有多重要。明确的架构特征出现在需求文档或其他特定说明中。
在图中，故意选择三角形：每个定义元素都支持其他元素，而后者又支持系统的整体设计。三角形创建的支点说明了以下事实，即这些架构特征经常相互交互，从而导致架构师在折衷一词中普遍使用。
已列出架构特征（部分）
架构特征存在于整个软件系统中，范围从低级代码特征（例如模块化）到复杂的操作问题（例如可伸缩性和弹性）。尽管过去曾尝试编成标准，但没有真正的通用标准存在。相反，每个组织都会对这些术语创建自己的解释。此外，由于软件生态系统变化如此之快，因此不断出现新的概念、术语、度量和验证，从而为架构特征定义提供了新的机会。
尽管数量众多、规模庞大，但架构师通常将架构特征分为几大类。以下各节描述了一些示例。
运维架构特征
运维架构的特性涵盖了性能、可伸缩性、弹性、可用性和可靠性等功能。下表列出了一些运维i架构特征。
表——一般运维架构特征
| 名词 | 定义 |
|---|---|
| 可用性 | 系统将需要可用的时间（如果是24/7，则需要采取一些措施以使系统在发生任何故障时能够快速启动并运行）。 |
| 连续性 | 灾难恢复能力。 |
| 性能 | 包括压力测试、峰值分析、所使用功能的频率、所需容量和响应时间的分析。性能测试有时需要自己进行，需要几个月的时间才能完成。 |
| 可恢复性 | 业务连续性要求（例如，在发生灾难的情况下，要求系统多长时间重新上线？）。这将影响备份策略和对冗余硬件的需求。 |
| 可靠性/安全性 | 评估系统是否需要是故障安全的，或者是否以影响生命的方式对任务至关重要。如果失败，是否会花费公司大量资金？ |
| 坚固性 | 如果互联网连接中断，断电或硬件故障，则可以在运行时处理错误和边界条件。 |
| 可扩展性 | 系统随着用户或请求数量的增加而执行和运行的能力。 |
运维架构特征与运维和DevOps关注点严重重叠，在许多软件项目中形成了这些关注点的交集。
结构架构特征
架构师必须关注代码结构。 在许多情况下，架构师对代码质量问题负全责或共同承担责任，例如良好的模块化，组件之间的受控耦合，可读代码以及许多其他内部质量评估。 下表列出了一些结构架构特征。
表——结构架构特征
| 名词 | 定义 |
|---|---|
| 可配置性 | 最终用户能够轻松地（通过可用的界面）更改软件配置的各个方面。 |
| 可扩展性 | 插入新功能的重要特性。 |
| 可安装性 | 易于在所有必要平台上安装系统。 |
| 杠杆/重用 | 能够跨多个产品利用通用组件的能力。 |
| 本土化 | 在数据字段的输入/查询屏幕上支持多种语言；报告，多字节字符要求以及度量单位或货币。 |
| 可维护性 | 应用更改并增强系统有多容易？ |
| 可移植性 | 系统是否需要在多个平台上运行？ （例如，前端是否需要针对Oracle和SAP DB运行？ |
| 可支持性 | 该应用程序需要什么级别的技术支持？调试系统中的错误需要什么级别的日志记录和其他功能？ |
| 可升级性 | 能够轻松/快速地从该应用程序/解决方案的先前版本升级到服务器和客户端上的较新版本。 |
横切架构特征
尽管许多架构特征属于易于识别的类别，但许多特征属于不合理的分类，但却构成了重要的设计约束和考虑因素。 下表说明了其中一些。
表——横切架构特征
| 名词 | 定义 |
|---|---|
| 辅助功能 | 访问您的所有用户，包括诸如色盲或听力障碍等残障人士。 |
| 可归档性 | 一段时间后是否需要存档或删除数据？ （例如，客户帐户将在三个月后删除或标记为已过时并存档到辅助数据库中以备将来访问。） |
| 认证方式 | 安全要求，以确保用户是他们所说的。 |
| 授权书 | 确保用户只能访问应用程序中某些功能的安全性要求（按用例、子系统、网页、业务规则、字段级别等）。 |
| 法律 | 系统运行在哪些立法约束下（数据保护、Sarbanes Oxley、GDPR等）？公司需要什么保留权？关于构建或部署应用程序方式的任何规定？ |
| 隐私 | 能够向公司内部员工隐藏事务（加密的事务，因此，即使DBA和网络架构师也看不到它们）。 |
| 安全 | 数据需要在数据库中加密吗？加密用于内部系统之间的网络通信？远程用户访问需要使用哪种身份验证？ |
| 可支持性 | 该应用程序需要什么级别的技术支持？调试系统中的错误需要什么级别的日志记录和其他功能？ |
| 可用性/可实现性 | 用户通过应用程序/解决方案实现其目标所需的培训水平。可用性要求与任何其他架构问题一样，都必须得到认真对待。 |
任何架构特征列表都必然是不完整的列表。 任何软件都可以基于独特因素来发明重要的架构特征。
此外，许多先前的术语不精确且含糊不清，有时是由于细微的差别或缺乏客观的定义。例如，互操作性和兼容性可能看起来是等效的，这在某些系统中是正确的。但是，它们之间存在差异，因为互操作性意味着易于与其他系统集成，而后者又意味着已发布的，已记录的API。另一方面，兼容性更关注行业和领域标准。另一个例子是学习能力。一个定义是用户学习使用软件的难易程度，另一个定义是系统可以自动了解其环境以使用机器学习算法进行自我配置或自我优化的级别。
许多定义重叠。例如，考虑可用性和可靠性，它们几乎在所有情况下都重叠。但是请考虑基于TCP的互联网协议UDP。 UDP通过IP可用，但不可靠：数据包可能会乱序到达，接收方可能不得不再次要求丢失数据包。
没有完整的标准列表。国际标准组织（ISO）发布了按功能组织的列表，与我们列出的许多功能重叠，但主要是建立了不完整的类别列表。以下是一些ISO定义：
性能效率
相对于已知条件下使用的资源量的性能度量。这包括时间行为（响应的度量、处理时间和/或吞吐率的度量），资源利用率（使用的资源的数量和类型）和容量（超出最大已建立限制的程度）。兼容性
产品、系统或组件可以在共享相同硬件或软件环境的同时与其他产品、系统或组件交换信息和/或执行其所需功能的程度。它包括共存（可以在与其他产品共享公共环境和资源的同时有效地执行其所需的功能）和互操作性（两个或多个系统可以交换和利用信息的程度）。易用性
用户可以针对其预期目的有效、高效且令人满意地使用该系统。它包括适当性可识别性（用户可以识别软件是否适合他们的需求）、可学习性（用户可以轻松学习如何使用软件）、用户错误保护（防止用户犯错误）和可访问性（使软件可用）给具有最广泛特征和能力的人）。可靠性
系统在指定条件下指定时间段内运行的程度。此特征包括以下子类别：成熟度（软件是否满足正常运行下的可靠性需求）、可用性（软件可运行且可访问）、容错（软件是否在硬件或软件故障的情况下仍按预期运行）和可恢复性（通过恢复任何受影响的数据并重新建立系统的所需状态，软件可以从故障中恢复）。安全
该软件可以保护信息和数据的程度，从而使人员或其他产品或系统拥有与其权限类型和授权级别相适应的数据访问程度。这一系列特征包括机密性（只有授权访问的人才能访问数据）、完整性（软件可防止未经授权访问或修改软件或数据）、不可否认性（可以证明已采取行动或事件）、问责制（是否可以跟踪用户的用户操作）和真实性（证明用户身份）。可维护性
表示开发人员可以修改软件以对其进行改进，纠正或使其适应环境和/或要求的变化的有效性和效率。此特性包括模块化（软件由离散组件组成的程度），可重用性（开发人员可以在多个系统中使用资产或用于构建其他资产的程度），可分析性（开发人员如何轻松地收集有关组件的具体指标）软件），可修改性（开发人员可以在不引入缺陷或不降低现有产品质量的情况下修改软件的程度）和可测试性（开发人员及其他人员测试软件的容易程度）。可移植性
开发人员可以将系统，产品或组件从一种硬件，软件或其他操作或使用环境转移到另一种环境的程度。此特征包括适应性的子特性（开发人员可以有效地并有效地使软件适应不同或不断发展的硬件、软件或其他操作或使用环境）、可安装性（可以在指定的环境中安装和/或卸载软件）和可替换性（开发人员以其他软件轻松替换功能）。
ISO列表中的最后一项针对软件的功能方面，我们认为它不属于该列表：
- 功能适用性
此特性表示在特定条件下使用时，产品或系统提供满足规定和隐含需求的功能的程度。此特征由以下子特征组成：- 功能完整性
功能集涵盖所有指定任务和用户目标的程度。 - 功能正确性
产品或系统以所需的精度提供正确结果的程度。 - 功能适当性
功能在多大程度上促进了特定任务和目标的完成。这些不是架构特征，而是构建软件的动机要求。这说明了如何思考架构特征和问题域之间的关系。
- 功能完整性
权衡与最差的架构
由于多种原因，应用程序只能支持我们列出的部分架构特征。首先，每个受支持的特征都需要进行设计工作，也许还需要结构上的支持。其次，更大的问题在于以下事实：每个架构特征通常会对其他特征产生影响。例如，如果架构师想要提高安全性，那么几乎可以肯定会对性能产生负面影响：应用程序必须进行更多的动态加密，隐藏私密信息的间接操作以及可能降低性能的其他活动。
隐喻将有助于说明这种相互联系。显然，飞行员经常难以学习如何驾驶直升机，因为这需要对每只手和每只脚进行控制，而改变一只手会影响另一只手。因此，驾驶直升机是一项平衡的工作，它很好地描述了选择架构特征时的权衡过程。架构师设计支持的每种架构特征都可能使总体设计复杂化。
因此，架构师很少遇到能够设计系统并使每个架构特征最大化的情况。通常，决策归结为几个相互竞争的问题之间的权衡。
提示
永远不要追求最佳架构，而要追求最差的架构。
太多的架构特征导致通用解决方案试图解决每个业务问题，并且这些架构很少起作用，因为设计变得笨拙。
这表明架构师应该努力设计架构，使其尽可能地迭代。如果您可以更轻松地对架构进行更改，则可以减少在第一次尝试中发现确切正确内容的压力。敏捷软件开发最重要的教训之一就是迭代的价值。这在软件开发的各个级别（包括架构）都适用。