InfoQ 中文站架构社区 2007 年度十大新闻

架构社区是年轻的 InfoQ 里面最年轻的一个社区，诞生只有半年时间。在“架构”这个意思不是很明确的大词背后，我们倒是做了不少实实在在的讨论。

其实在这个社区里没有什么“新闻”，这么说的原因是，一方面报道的内容多半不是新闻事件，而是言论交锋；另一方面讨论的内容也常常是把我们习以为常的旧东西再拿出来重新剖析。而且讨论的问题也不见得会有一定的答案，不过我们的目的也不是寻找公式化的回答，我们要的是想清楚每个选择的利弊和权衡。

要是能让开发者反思，再反思，这个社区的目的也就达到了吧。

1. DSL：单一语言开发的终结者？
许多年以来，对于软件项目，企业软件开发的主流实践一直都倾向于在单一的通用编程语言上进行标准化，从而使得 Java 和 C#成为今天编程语言的主流选择。随着越来越多的目光开始投向 DSL，也许我们的前脚已经踏在了一道新的门槛之上，向前望去，我们会发现在软件项目中采用多种语言已经成为一个标准，但 80 年代和 90 年代初出现的问题不会重现。

点评：DSL 离“领域专家说的语言”还很远，“让领域专家去编程”已经基本被 MDA、BPM 的实践所否定。不过，我们已经从为工作选择合适的工具、框架，进步到了为工作选择合适的语言，不管 OOP、AOP、FP……通通为我所用。再说，XML 配置、连贯接口这些不是很像语言的 DSL，我们已经用很久了吧。

2.真正的线性可伸缩性需要新的模式和中间件架构吗？
Nati Shalom 声称已有基于分层的中间件不能用于真正的线性可伸缩性。他提出了新的基于自给自足处理单元的中间件栈（middleware stack）作为替代，它支持分区 / 向外扩展（scale-out）模型。几年前，微软的 Pat Helland 就提出了某种事务性模式及形式描述，它们可被用在被他称为准无限可伸缩的系统中。

点评：Web 2.0 一流行，可伸缩性就很敏感了。数据分区、缓存共享、读写分离……一直到极端的完全无状态模型，那么多努力的成果让投入 / 产出的曲线多少变直了一些。棘手的事务问题这此也给出了不错的解决方案。不过，成天可伸缩性挂在嘴边的人，还是要先问一下自己，到底什么是可伸缩性。

3. API 设计的“不可承受之轻”
API 的设计影响着所有的开发者。有些 API 用起来很舒服，而有些则用起来让人焦头烂额，更有甚者，让人完全丧失了继续用这套 API 来做开发的勇气。但它们的区别在哪里呢？是哪种品质会让一套 API 易用而另一套复杂难解？ACM Queue 最近刚发布了 Michi Henning 的一篇有关 API 设计的文章，在文中作者对这些方面进行了分析。

点评：API 设计是一件基本但重要的事情，但好像我们都没有这方面的系统教育。

4.软件架构的十大错误
IASA 成员 Eoin Woods 发表了一篇文章讲述他所认为的十大软件架构错误——常常要碰得头破血流才会得到的一些教训。

点评：每个人都犯过的错误，也还要再犯的错误。希望下次再犯的时候，知道自己错在哪里就好了。这样想太悲观了吗？

5.一图胜千言?
一图总是胜过千言？Dean Wampler 在新文章《为什么我们要写代码而不只是画图就好》中主张，在软件行业里，前面那句话通常要反过来说才对。

点评：不管图形还是文字，说到底还是要看它的抽象程度适合不适合要表达的内容。

6.为灵活性和健壮性而设计：异步消息模型、OOP 和函数式编程
按照 Pragmatic Programmers 的说法在 OOP 中最好避免围绕返回值来设计。Michael Feathers 认为最好同时也使用异步消息模型，这样有助于提高适应性和健壮性。这样的做法与 Erlang 的模型相吻合，虽然违背了一些纯函数式编程的原则。

点评：异步、无状态模型的优点很多人都看得到，但要是谈到在具体的用例中采用异步、无状态模型，很多人就说“这件事情本质上就是同步的”——真的吗？ 还是你需要好好换一下思维方式？

7. RDBMS 是不足够的
在服务的世界里，RDBMS 并不能适合所有的问题。面向文档的分布式数据库（Document Oriented Distributed Databases）试图解决该问题，并为存储文档再提供一种新途径。CouchDB（以 Erlang 编写）正从 Alpha 阶段日渐向前发展。InfoQ 找来了 Anthony Eden，他正在开发的 RDDB 用 Ruby 实现了同样的概念。

点评：RDBMS 的地位难以撼动，但在面对分布式服务的时候，有必要打破一些 RDBMS 的规条，才能满足性能和可伸缩性的需求。这又是一次新的尝试。

8. Duck Typing 与协议 vs. 继承
最近在 RubyTalk 邮件列表中发生了关于何时使用 is_a? 以及何时使用 respond_to? 的争论。这强调了这样一种状况：对象可以都响应同样的接口，但是却没有共同的超类。让我们来分析下这次争论，然后看看诸如 Smalltalk、Erlang 和 Scala 其他这些编程语言是如何解决的。

点评：最基本的 OO 概念也会被翻出来“学而时习之”。跨出语言的局限才能把概念的本质看得更清楚一点。

9.依赖注入是否值得？
在博客的世界里进行了一场关于使用依赖注入之优点和缺点的有趣讨论。论题是：依赖注入是否真的值得？

点评：用惯用熟的 DI，为什么要用它倒成了问题。且不管反方的观点成不成立，让我们再想清楚，为什么要用依赖注入——松耦合。

10.预先设计的大架构——过早考虑伸缩性之一例？
请看看博客作者们对“过早考虑可伸缩性”这个问题的回应。问题是——在设计应用程序的时候，应该花多少精力去为伸缩性打基础？

点评：伸缩性不是优化，它是一项需求，我们从一开始就应该考虑它。 对未来的规模估计不足，那到时候就要返工，可能使业务的发展停滞；如果估计得过分，那又是浪费，而且可能错失市场时机。理论上是存在一个投入 / 产出比的拐点，可是它在哪里呢？