1.1 软件架构概念的分类

第1章  解析软件架构概念

不积跬步，无以至千里。——《荀子•劝学篇》

什么是架构？如果你问五个不同的人，可能会得到五种不同的答案。
——Ivar Jacobson，《AOSD中文版》

很多人都试图给“架构”下定义，而这些定义本身却很难统一。
——Martin Fowler，《企业应用架构模式》

不积跬步，无以至千里。作为本书的第1章，我们首先讨论软件架构的概念。为了给读者带来实感，我们将结合流行的MVC架构以及一个名为PM Tool的项目管理系统的案例故事进行讲解。

值得说明的是，人们对“Architecture”有着不同的中文叫法，比如架构、构架和体系结构等。本书将一以贯之地采用“架构”的叫法；当然，当引用原文或提及书名时将保留原来的叫法。

1.1  软件架构概念的分类

一个词（比如“电脑”），可能并不代表一件单独的东西，而是代表了一类事物。这个一般性的表述就是我们通常所说的“概念”。

也许读者期待一个干净利落的软件架构概念，但这有点儿难。对此，Martin Fowler给出的评价是，“软件业的人乐于做这样的事——找一些词汇，并将它们引申到大量微妙而又相互矛盾的含义中。一个最大的受害者就是‘架构’这个词。……很多人都试图给‘架构’下定义，而这些定义本身却很难统一。”

的确如此。由于软件架构的概念有太多的版本，这已经对软件架构师的工作，乃至整个软件开发活动造成了不少麻烦。

 造成交流上的误解。此君说的软件架构，和彼君理解的软件架构未必是一回事；
 造成实践上的障碍。软件架构设计领域和其他任何复杂领域一样，即使对基本概念和思想有了清晰的认识，依然未必能够保证实践畅通无阻。更何况是在架构概念本身还处于“微妙的相互矛盾”之中的情况下呢？
 造成分工合作中的不一致。架构设计究竟要覆盖哪些范围？架构设计应进行到什么程度？对这两个问题认识上的不一致当然也和架构概念混乱有关。一方面，开发者对架构的明确程度期望甚高；另一方面，架构师的架构设计方案却是高来高去；这就造成了大量设计空白，最终往往靠临时拍脑袋或临时商量来决定，于是软件质量下降、协作开发混乱就在所难免了；
 造成其他概念乘虚而入。我们的大脑中“驻扎”了很多概念，“软件架构”一词如此流行，以至于每个软件人员的大脑中都有它的一席之地。但由于软件架构的概念本身没有一个具有压倒性优势的定义充当“旗手”，致使许多人大脑中贴着“软件架构”标签的位置已经被其他概念占据了——典型的片面认识包括架构就是结构、架构就是基础设施（infrastructure）、架构就是框架（Framework），等等。

本书认为，鉴于软件架构概念的混乱，应该采取分类的办法。这是因为，通过分类可以在包容细节差异的基础上明确共性，达到“概念总体上的清晰”。笔者的经验证明，这种务实的做法是有利于实践的。

下面，我们将软件架构概念分为两大流派：组成派和决策派。

1.1.1  组成派

Mary Shaw在《软件体系结构：一门初露端倪学科的展望》中，为“软件架构”给出了非常简明的定义：
软件系统的架构将系统描述为计算组件及组件之间的交互（The architecture of a software system defines that system in terms of computational components and interactions among those components.）。

必须说明，上述定义中的“组件”是广泛意义上的元素之意，并不是指和CORBA、DCOM、EJB等相关的专有的组件概念。“计算组件”也是泛指，其实计算组件可以进一步细分为处理组件、数据组件、连接组件等。总之，“组件”可以指子系统、框架（Framework）、模块、类等不同粒度的软件单元，它们可以担负不同的计算职责。
上述定义是“组成派”软件架构概念的典型代表，有如下两个显著特点：

（1）关注架构实践中的客体——软件，以软件本身为描述对象；
（2）分析了软件的组成，即软件由承担不同计算任务的组件组成，这些组件通过相互交互完成更高层次的计算。

1.1.2  决策派

下面来看看RUP（Rational Unified Process，Rational统一过程）中的软件架构定义。

软件架构包含了关于以下问题的重要决策：

 软件系统的组织；
 选择组成系统的结构元素和它们之间的接口，以及当这些元素相互协作时所体现的行为；
 如何组合这些元素，使它们逐渐合成为更大的子系统；
 用于指导这个系统组织的架构风格：这些元素以及它们的接口、协作和组合。

软件架构并不仅仅注重软件本身的结构和行为，还注重其他特性：使用、功能性、性能、弹性、重用、可理解性、经济和技术的限制及权衡，以及美学等。

上述定义看似冗长，但其核心思想非常明确：软件架构是在一些重要方面所作出的决策的集合。

该定义是“决策派”软件架构概念的典型代表，有如下两个显著特点：

（1）关注架构实践中的主体——人，以人的决策为描述对象；
（2）归纳了架构决策的类型，指出架构决策不仅包括关于软件系统的组织、元素、子系统和架构风格等几类决策，还包括关于众多非功能需求的决策。