一般来说，软件产品要取得成功，必须同时兼顾需求和设计。而且归根到底，所有的精妙设计都源自于实际的需求。如果没有实际的需求，那么不论设计多么精妙，只是徒增成本而已。下面我们来探讨一下设计是如何来满足各种需求的。

一、功能性。功能性需求是最容易想到的那部分需求，但是要确保系统功能的完整实现，仍需要精心设计。通常我们通过领域分析来学习并确定系统功能，通过划分子系统和功能模块来实现对功能性的关注点分离。例如，在《彩色UML建模》一书中，将一个企业信息系统分解成了12个子系统，分别是：物料资源管理、设施管理、制造管理、库存管理、产品销售管理、现金销售管理、客户账户管理、人力资源管理、关系管理、项目活动管理、会计管理和文档管理。

二、可靠性。不同的系统对可靠性有不同的要求，即平均无故障时间（MTBF）达到多少，或可用性达到几个9.我们知道，一般系统的组成部件越多，出错的概率越大。但这只是故事的一个方面。要想提高系统的可用性，就要为系统增加更多的组成部件，即提供冗余部件。无单点故障的设计，正是为了提高系统的可用性。RAID以及专为容错而设计的“NonStop”系列计算机和操作系统，都是针对系统的可靠性需求所做的设计。现在，人们越来越多地使用计算机集群来实现高可用性（HA）。安全性也是可靠性的一个方面，为此架构师会设计一些机制，牺牲一点性能和易用性。

三、易用性。为了追求易用性，工业设计师和人机界面设计师殚思竭虑，设计出一些操作简单方便、适用于各种人群、各种场合的产品。IPhone以及奋起直追的Android手机就是这样的产品。易用性为用户节约了操作时间，带来了价值。同样，Photoshop的快捷键设计也是为了提高易用性，它只是有一条比较陡的学习曲线，学习成本较高而已。这些易用性设计的背后，都有真真切切的用户需求。GUI是为了易用性，命令脚本也是为了易用性。

四、效率。不存在无限的资源，所以系统必然在效率方面有所要求。算法设计中的时间复杂度分析和空间复杂度分析，是每一个软件架构设计师必备的能力。如果需要让一台服务器服务尽可能多的并发用户，如果需要让软件运行在手机上，那么架构师就必须为资源使用效率而设计，考虑用时间换取空间或是反之。是否使用缓存机制？使用哪种缓存机制？架构师会在需要的时候仔细斟酌。

五、可维护性。系统的运营维护成本才是总体拥有成本中的大头。所以，好的架构师知道，需要为运营维护而设计。复制/粘贴代码是不好的行为。系统需要具备审计追踪能力、需要能记录日志。架构的设计应该尽可能满足高内聚低耦合的原则。需要有一些基础设施来保证降低系统故障诊断成本和修复成本。SOA治理主要是从企业系统的可维护性需求出发来考虑问题的。

六、可移植性。为什么Java会流行？因为系统有可移植性需求。人们甚至愿意为可移植性而牺牲一点效率。但是真正的架构师知道，不用Java也能实现可移植性，用了Java也可能不能移植。Java只是架构师在面对可移植性需求时的一个选择。有的系统用Java设计，但只能运行在Windows平台或Oracle数据库上，这样的故事我们听到的不少。Java虚拟机帮助我们实现对可移植性的关注点分离，并带来一些开销。

七、可伸缩性。进入互联网时代，信息系统有了根本的变化，即强调可伸缩性。设计中的系统如果获得成功，可能在不远的将来需要承受几个数量级的客户。这就要求系统有很好的可伸缩性。在这种情况下，不论使用怎样的架构风格和编程语言，架构师必须为可伸缩性而设计。Google的Map/Reduce技术和Apache的Hadoop项目就是很好的例子，架构师设计出一些基础设施，实现了可伸缩性的关注点分离。

虚拟机、SOA、RESTful、云计算、SaaS、PaaS、Android,无论是哪种架构，你都可以找出隐藏在这些架构设计背后的需求。哪种适合你？只有实践能给出答案。所以，实践是检验真理的唯一标准。没有什么比好的理论更可实践的了。纸上得来终觉浅，绝知此事要躬行。学而实习之，不亦乐乎？实践是认识的来源，实践是认识发展的动力，实践是认识的最终目的。