架构概念.pdf

不积跬步，无以至千里。—— 《荀子·劝学篇》 什么是架构？如果你问五个不同的人，可能会得到五种不同的答案。 ——Ivar Jacobson ，《AOSD 中文版》 很多人都试图给“架构”下定义，而这些定义本身却很难统一。 ——Martin Fowler ，《企业应用架构模式》 不积跬步，无以至千里。作为本书的第 1 章，我们首先讨论软件架构的概念。为了给读者带 来实感，我们将结合流行的 MVC 架构以及一个名为 PM Tool 的项目管理系统的案例故事进行讲 解。 值得说明的是，人们对“Architecture ”有着不同的中文叫法，比如架构、构架和体系结构 等。本书将一以贯之地采用“架构”的叫法；当然，当引用原文或提及书名时将保留原来的叫 法。 一个词（比如“电脑”），可能并不代表一件单独的东西，而是代表了一类事物。这个一般性 的表述就是我们通常所说的“概念”。 也许读者期待一个干净利落的软件架构概念，但这有点儿难。对此，Martin Fowler 给出的评 价是，“软件业的人乐于做这样的事——找一些词汇，并将它们引申到大量微妙而又相互矛盾的 含义中。一个最大的受害者就是‘架构’这个词。……很多人都试图给‘架构’下定义，而这些 定义本身却很难统一。” 的确如此。由于软件架构的概念有太多的版本，这已经对软件架构师的工作，乃至整个软件 开发活动造成了不少麻烦。 4 造成交流上的误解。此君说的软件架构，和彼君理解的软件架构未必是一回事； 造成实践上的障碍。软件架构设计领域和其他任何复杂领域一样，即使对基本概念和 思想有了清晰的认识，依然未必能够保证实践畅通无阻。更何况是在架构概念本身还 处于“微妙的相互矛盾”之中的情况下呢？ 造成分工合作中的不一致。架构设计究竟要覆盖哪些范围？架构设计应进行到什么程 度？对这两个问题认识上的不一致当然也和架构概念混乱有关。一方面，开发者对架 构的明确程度期望甚高；另一方面，架构师的架构设计方案却是高来高去；这就造成 了大量设计空白，最终往往靠临时拍脑袋或临时商量来决定，于是软件质量下降、协 作开发混乱就在所难免了； 造成其他概念乘虚而入。我们的大脑中“驻扎”了很多概念，“软件架构”一词如此 流行，以至于每个软件人员的大脑中都有它的一席之地。但由于软件架构的概念本身 没有一个具有压倒性优势的定义充当“旗手”，致使许多人大脑中贴着“软件架构” 标签的位置已经被其他概念占据了——典型的片面认识包括架构就是结构、架构就是 基础设施（infrastructure ）、架构就是框架（Framework ），等等。 本书认为，鉴于软件架构概念的混乱，应该采取分类的办法。这是因为，通过分类可以在包 容细节差异的基础上明确共性，达到“概念总体上的清晰”。笔者的经验证明，这种务实的做法 是有利于实践的。 下面，我们将软件架构概念分为两大流派：组成派和决策派。 Mary Shaw 在《软件体系结构：一门初露端倪学科的展望》中，为“软件架构”给出了非常 简明的定义： 软件系统的架构将系统描述为计算组件及组件之间的交互（The architecture of a software system defines that system in terms of computational components and interactions among those components. ）。 必须说明，上述定义中的“组件”是广泛意义上的元素之意，并不是指和 CORBA 、 DCOM 、EJB 等相关的专有的组件概念。“计