软件架构基础 4: 你的架构需要考虑到的特性
▲ 点击上方"多颗糖"关注公众号
一个公司决定用软件解决一个特定的问题的时候，公司会去收集该软件的需求清单。需求可以说是软件开发的基础，但除了需求以外，架构师有很多因素需要去考虑。
下图在第 1 章出现过：

架构师可能会参与收集需求，但架构师一个关键的职责是要发现、定义其它和具体需求没有直接关系的东西，这些东西称之为架构特性（architectural characteristics）。
一个架构特性满足三个标准：
指定了一个非领域（业务）设计的考虑因素：例如，一个重要的架构特性是应用程序的性能水平，而这一点往往不会出现在需求文档中；
影响结构上的设计：这个架构特性是否需要特殊的结构才能成功？例如，考虑要支持支付功能的系统，可以选择第三方支付（只需要符合安全即可嵌入），还是应用自己处理支付（这需要设计特定的支付模块），这将导致不同的架构设计；
对应用的成功至关重要：应用程序可以支持大量的架构特性，但每个架构特性的支持都会增加设计的复杂性，因此，架构师的一项工作是选择最少的架构特性；

架构特性主要分为显性的和隐性的。
隐性的很少出现在需求中，但它们却是项目成功的必要条件。例如，可用性、可靠性和安全性几乎是所有应用的基础，然而它们很少在设计文档中被提及。
架构师必须在分析阶段利用他们的知识来发现这些架构特性。
架构特性列表
架构特性存在于软件系统的广泛范围内，从代码特性如模块化，到复杂的问题如可扩展性和弹性。由于软件生态系统变化如此之快，新的概念、术语、措施和验证不断出现，并不存在真正的标准。但是架构师通常将架构特性分为下面几大类：
运行架构特性
运行架构特性涵盖了性能、可扩展性、弹性、可用性和可靠性等能力。
结构架构特性
架构师也必须关注代码结构。在许多情况下，架构师对代码质量问题负有单独或共同的责任，如良好的模块化、组件之间的可控耦合、可读的代码以及一系列其他内部质量评估。
交叉架构特性
许多特征不在分类范围内或无法分类，却形成了重要的设计限制和考虑因素。
其它架构特性
ISO 也发布过软件质量的列表，参见：https://iso25000.com/index.php/en/iso-25000-standards/iso-25010
主要分为下图的各大类，在此不再展开。

任何架构特征列表必然是不完整的，任何软件都可能根据独特的因素发明重要的架构特征。
权衡架构
由于各种原因，应用程序只能支持列出的几个架构特性：
每一个被支持的特性都需要设计上的努力，或许还需要结构上的支持；
更大的问题在于，每个架构特性往往会对其他特性产生影响。例如，如果架构师想要提高安全性，几乎肯定会对性能产生负面影响；
因此，架构师很少会遇到这样的情况：他们能够设计一个系统，并将每一个架构特性最大化。更多的情况是，决定要在几个相互竞争的问题之间进行权衡。
过多的架构特性导致设计变得笨重。
架构师应该努力使架构设计尽可能地迭代。如果能更容易地对架构进行修改，就可以减少在第一次尝试中就设计出完全正确的东西的压力。敏捷软件开发最重要的经验之一就是迭代的价值，这在软件开发的各个层面都适用，包括架构。
（这本书一直在强调，在软件架构和开发中，快速迭代和敏捷的重要性。）
永远不要追求最佳的架构。
相关阅读
软件架构基础 2: 架构思维
软件架构基础 3: 什么是好的模块化代码？高内聚、低耦合如何衡量？
欢迎关注我的公众号：