Question

不管你采用哪种流程（传统和计划驱动，或者轻量和可适配的），都有一套常见的东西真正驱动、影响和塑造了最终的软件架构。

功能需求

为了设计软件，你需要了解要满足的目标。如果这听起来天经地义，那是因为确实如此。话虽如此，但有的团队对软件应该向最终用户提供的特性还没有高层次理解，就设计甚至构建软件。有人可能会称之为敏捷，但我说这叫愚蠢。特性或用户故事清单（比如Scrum产品订单1），即使粗糙短小，也是必不可少的。需求驱动架构。

1http://en.wikipedia.org/wiki/Scrum_%28software_development%29#Product_backlog

质量属性

非功能需求代表的质量属性反映了服务等级，如性能、可伸缩性、可用性、安全性等。这些属性主要是技术方面的，可以对最终的架构产生巨大影响，特别是如果你正在构建“高性能”系统，或者你想达到“谷歌级”的运行规模。实现非功能需求的技术解决方案通常是交叉的，因此需要合并到你所构建系统的基础中。向已有的代码库加入高性能、可伸缩性、安全性、可用性等通常极其困难且耗时。

约束

我们生活在有约束的现实世界中。例如，你任职的组织可能对技术选型、部署平台等有一系列细致的约束，能做什么，不能做什么。

原则

约束通常是强加于你的，而原则是你为了将一致性和清晰度引入最终代码库而想采用的原则（例如编码规范、自动化测试的使用等）或架构的原则（如分层策略，架构模式等）。

理解影响

任何时候当你开始为一个新的软件系统工作或扩展已有的软件系统，在高层次上理解需求、约束和原则都至关重要。为什么？简言之，要开始设计选型，这是你所需知识的基本水平。

首先，了解这些东西可以帮助减少摆在你面前的可选项，特别是如果你发现驱动力包括了复杂的非功能性需求或者像部署平台的限制之类的主要约束。T.S.艾略特（T.S.Eliot）说过：

当被迫工作在一个严格的框架下，想象力被迫发挥到极限，迸发出丰富的点子。完全的自由可能会让工作变得杂乱无序。

其次，也许是最重要的，那就是根据特定的目标和语境，做出“明智”的设计决策。如果不了解金融风险系统相关的性能（比如计算复杂度）、可伸缩性（比如数据量）、安全性和审计等需求，就开始为其设计解决方案，你设计出的解决方案很可能不符合目标。

软件架构谈论的是重要的设计决策，其重要性以变动的成本来衡量。对于那些从根本上塑造了最终软件架构的重要决策而言，起点是在高层次上对需求、约束和原则的理解。早些理解它们，将有助于避免将来昂贵的返工。