2007年，架构领域有不少词汇常被提起，有人会觉得它们是Buzzword，有人会觉得是陈年老调。但Buzzword能帮助人们改变对事物的看法，陈年老调也会在实践中得到修正。我们的进步总是这样，慢慢从喧嚣里沉淀出一些实实在在的东西，又给旧瓶装上一点点新酒。

　　有了落脚处的DSL

　　所谓架构，可以说是看问题的一系列视角，每个视角体现出一个需要关心的方面，同时将不相关的其它信息隐藏。换言之，就是一系列的抽象。为了解决抽象问题，面向语言编程（LOP）和领域特定语言（DSL）继OOP、AOP之后又一次提升了抽象的层次。

　　LOP看似近年才兴起，实则可追溯到Lisp和Smalltalk。Ruby等动态语言的流行及其元编程能力显然是让人们再次想起DSL的原因之一。再加上Java和.NET这两个主流平台加入函数式编程能力和对脚本语言、动态语言的支持，DSL已有了成长的土壤。

　　面向对象为描述问题域解决了词汇，透过DSL，我们进一步抽象出把词汇联系起来的语法。使用与领域专家一样的语言来编写程序，显然更容易将领域模型迅速转化成代码。用合适的概念来表述问题，不仅简洁，而且有助于消除歧义和误解，甚至可因此而减轻测试负担。

　　DSL强调可读性，对领域专家的可读性。应当注意的是，强调对领域专家的可读性并不意味着让领域专家来写程序，我们在MDA和BPM上已经得到过教训。

　　作为内部DSL的一种形式，连贯接口已广为熟知，也成为了API设计的一个重要原则。这种方式在当前有限的工具和语言特性支持下，让我们体会到了DSL的优雅。当前DSL，尤其是外部DSL缺乏的是工具支持上突破性进展，人们还在摸索什么才是Language Workbench的最佳实践。

　　混合语言编程还有另一种形式。JRuby、Groovy、DLR语言，它们把相对较新的一些动态语言搬到了原先为静态语言设计的平台上，既利用了平台原有的成熟类库、框架和VM，又能从动态语言灵活性中得益，反过来又促使平台增加更多动态特性。这种趋势已延续好几年，但今年JRuby在一些大型应用中的表现很好证明了这种方式的有效性。

　　虽然我们很可能还要好多年，才会像现在为项目选择框架和类库一样方便地选择并混合使用不同的语言，但至少LOP给我们带来了另一种看问题的角度，会帮助我们为模型找到适当的表达形式。DDD所追求的Ubiquitous Language，用DSL来表达是不是最佳方式呢？

　　热到不行的RIA/SOA

　　Ajax的流行刺激出了不少改变，比如RIA、Mashup、REST。他们背后都有一个共同想法，即把各种资源联系到一起。

　　在Web 2.0趋势鼓励下，Web应用纷纷向用户开放编程接口。面对越来越趋于开放的架构，我们需进一步强调解耦。SOA起了很大作用。通过“服务”，我们成功地把客户端的细节完全阻隔开。服务端专一的提供API，担当基础设施的角色。

　　进一步的发展又引出了Service Bus等概念，尤其在企业内部，通过SOA来实现资源整合是主流趋势。通过将企业资源重新规划、改造成“服务”以获得松耦合的系统群落，可以改善应对变化的能力，提升重用的程度，也降低了系统间实现互操作的难度。

　　随着AJAX的发展，人们日渐认识到浏览器的局限。因此Flex/AIR、JavaFX、Silverlight等新客户端技术相继出来，虽然成熟度不一，但设计理念都非常类似。各厂商之间激烈的竞争，虽然会有些混乱，但也会催生出更加完善的技术。

　　一方面，各种客户端技术都不约而同加入离线支持，让网络应用又再向桌面回归;另一方面又把办公软件、图像处理软件这样的传统桌面软件搬到线上，可以说差不多完全打破了软件和服务的界限。

　　RIA和SOA的结合给原有三层架构模型带来了若干变化趋势:从同质变成异质;从语言依赖变成语言独立;从中心化分层应用变成大规模分布式服务;从以代码为中心变成更加灵活的组合式应用;从请求/响应模型变成发布/注册事件模型。

　　RIA重点之一是可用性。发明RIA，不是为了花哨的界面，是为了改善用户体验。我们必须从用户直觉感受、生产力、个性化等方面去考虑，提高应用的交互能力，既要给用户提供充分信息，又不能让用户被信息淹没。

　　WS-*与REST停战

　　WS-*和REST口水仗打了一整年。与此同时WS-*的系列规范基本完整，软件支持也基本完善;REST信众也越来越多。WS-*和REST为我们实现SOA提供了两种思路。

　　对于开放、存在多种可能的客户端的应用，REST将交互行为限制在一个很小集合，让应用接口能轻易被各种客户端所理解。RESTful HTTP服务最大化地利用了HTTP的能力。不过，当建模的对象不适合套进“资源”时，REST就遇到了局限。而且REST作为一种风格和原则，并不存在业务上的规范、标准，这些都被推给应用的开发者去个别实现。

　　另一方面，WS-*为各种繁杂的业务需求定义了许多标准，设立了一个相当完整平台。WS-*过度复杂，但其软件的成熟可在一定程度上弥补这个问题，适当的框架让人们不必直面错综复杂的规范，只需选择所需组件。

　　各种WS-*规范的出现是有真实需求在背后的，REST也没办法绕过所有复杂问题。因此另一种调和的说法是，WS-*是以服务为中心的架构风格，而REST是以资源为中心的。很多框架和工具设计者已务实地着手让两者和平共处了。

　　伸缩性和并行

　　大规模网络应用让人们对伸缩性特别敏感。纵向提升伸缩性的空间非常有限，更合理的方案是横向发展。许多人都在试图增强语言对并行计算的支持，无论Java还是.NET都已有初步实现。函数式编程的无状态模型因能被方便转成并行而不出现副作用，因此成为研究热点之一。

　　Erlang依靠天生的并发和容错特征，吸引了很多目光。Erlang构造出大量的、相互间不共享状态的进程，然后通过异步消息完成进程间的通信。虽然应用还不多，但它的独特哲学，令人耳目一新。

　　与此类似，我们从Google、Amazon、eBay等互联网巨无霸身上也可看到，他们在架构上无一例外都选择了Scale-Out路线，其关键还是在于工作单元之间“不共享状态”。而且，采取这条路线常可一举三得地提升伸缩性、可靠性和性能。Scale-Out的困难是必须一开始就为伸缩性进行架构设计，否则事后很难补救。另一困难是，即便我们很清楚异步方式可提升伸缩性，仍然常常本能地认为事物是同步的，因此必须说服自己抛开先入为主的顽固想法。

　　领域驱动设计

　　领域驱动设计（DDD）不是什么新东西，但DDD重新理清了我们实践这些概念的方式。

　　DDD认识到对于同样的问题域，每个人建立的模型可能不一样。因此它关心如何评估和选择这些模型;如何运用模式来避开陷阱、避免设计出过度耦合的模型;如何让开发者与领域专家一起更深入地探索问题域，最后去芜存菁，获得对问题域的实质理解，并将理解转化成切合实际的软件设计。

　　DDD对架构的影响主要体现在职责分离上。通过对领域的专注，在设计时尽量屏蔽分层架构和基础设施干扰，让你能较清晰地观察事物如何安排才更自然、更合理。这样设计出来的核心模型也可避开对平台的依赖，对可维护性也有好处。

　　在工具支持不足的情况下，DDD也会遇到困难。如果无良好的基础设施，平台细节不可避免地会侵入到模型中，我们也不得不对设计作出折衷。另外，从理念上看，DSL应该可以和DDD成为完美的组合，虽然目前还缺乏实践，但很可能会成为下一阶段的热点。