假如一种架构风格已经不流行了，还有必要去研究具体的架构吗？

Fielding先生在他关于REST的博士论文中，大量用到了“架构风格”（Architectural Style）这个词。简单地用面向对象的方式来描述，一种架构风格代表了一组运行环境对于架构设计所造成的约束，它就好比是一个类或者一个接口，而具体的架构呢，则是某种架构风格的一个实例。

Fielding这篇论文是继GoF的《设计模式》之后，对我启发性最大的一本书。
现在国内外已经出版过的关于软件架构的专著已经汗牛充栋，加上各种“大师”的推荐，貌似这些书不可不读，不读则无法提升境界，不读则无法脱离苦海，不读则无法阳春白雪。有人还计划半年之内读完10余本架构设计的名著，通过这种方式速成为一名优秀的架构师。

不过这些书在我看来，都没有Fielding不到200页的博士论文来的实在。这些书有一个比较普遍的通病是，它们大多没有将某种架构的运行环境所导致的约束讲清楚，以至于读者误以为这些架构可以包治百病。如果真的有一种包治百病的万能架构，那么银弹就找到了，图灵奖就应该发给找到这种架构的这个人。不过图灵奖至今也没有发给过任何一个软件架构的研究者（包括优秀的Kent Beck、Erich Gamma和Martin Fowler），这说明其实这个领域还很不成熟。

很多软件架构方面的专著都喜欢引用Christopher Alexander的The Timeless Way of Building和A Pattern Language这两本书，作为设计模式思想的起源。
不过Alexander有一个重要的思想被他们忽略了。Alexander希望通过总结出一些建筑的模式，来研究不同的环境对于建筑所造成的约束。他希望建造出与环境完美协调（天人合一）的建筑。这些环境的约束包括文化上的、气候上、使用方便性上的等等约束。作为一名建筑师，如果不能理解他所设计的建筑必须与其所处的环境完美协调，他是不可能成为一名伟大的建筑师的。

对于软件来说，其运行的环境对于其架构所造成的约束同样非常重要。现在大多数的软件架构研究者仅仅只研究了软件的静态代码中的结构和重用问题，而并没有充分考虑软件在运行时的结构和约束。这是一个非常大的局限，Fielding在博士论文中明确地指出了这个局限。
例如：为什么SOAP在Web应用中并不适合，因为SOAP的性能太差了，所以Ajax和RIA应用不可能将SOAP作为自己首选的Web Remoting技术。为什么EJB2.x被Spring取代了，一个重要原因也是因为EJB2.x并没有充分考虑到运行环境的约束。当然EJB2.x对于软件设计、开发、测试、部署等方面也带来了很大的麻烦，所以最终被抛弃了。

理解运行环境对于软件架构所造成的约束，是成为一名优秀的架构师的关键。不理解这些约束，就没有能力设计开发出具有高伸缩性和良好可用性的应用。Design by buzzword的架构师，满世界都是，做这样一个架构师，你的价值何在呢？

所以，完全没有去读完10余本架构设计方面的名著，因为这些书纸上谈兵的成分太多了，而且它们都仅仅只是某种架构风格的实例。假如基于EJB2.x的J2EE应用这种架构风格已经不流行了，你再去花很多时间学习基于EJB2.x的架构设计有何价值？假如基于SOAP/WSDL/UDDI的Web Service已经不流行了，你再去花很多时间学习基于这些技术的架构设计有何意义？还是先搞清楚你要建造的应用的运行环境，这种运行环境的约束，目前存在有哪些架构风格，哪一种架构风格更适合你要建造的应用，这些才是更重要的。

环境所带来的约束，我来举一个例子，可能是在《面向使用的软件设计》或者哪本书中看到的，我懒的去查了。假设你为一个高山滑雪场设计了一个ATM机的应用，这个应用的输入设备是一个标准的ATM机键盘。你忽略了一个因素，这个地方非常寒冷，所有的人都带着厚厚的手套（很多还是无指的手套），而这个键盘要求他们必须要脱掉手套才能操作。即使你在这个应用中使用了GoF全部的23种设计模式，还使用了EJB3、JSF、AOP、IoC等等各种能令你自豪的buzzword，但是你的应用无疑是一个失败的应用，因为几乎没有人喜欢使用你的应用。无疑，you are a loser.