0.1 架构

软件业的人乐于做这样的事——找一些词汇，并把它们引申到大量微妙而又互相矛盾的含义。一个最大的受害者就是“架构”（architecture）这个词。我个人对“架构”的感觉是，它是一个让人印象深刻的词，主要用来表示“我们正在谈论重要的事情”。不过，我还是挺务实的，不会让我的愤世嫉俗影响到读者对本书的兴趣[1]。

很多人都试图给“架构”下定义，而这些定义本身却很难统一。能够统一的内容有两点：一点是“系统分解为部件的最高级别”；另一点是“系统中不易改变的决定”。越来越多的人发现：表述一个系统架构的方式不止一种；一个系统中也可能有很多种不同的架构，而且，对于什么在架构上意义重大的看法也会随着系统的生命周期变化。

Ralph Johnson经常在邮件列表上发帖，并提出一些令人关注的见解。就在我完成本书初稿的同时，他又发表了一些关于“架构”的观点。他认为，架构是一种主观上的东西，是专家级项目开发人员对系统设计的一些可共享的理解。一般地，这种可共享的理解表现为系统中主要的组件以及这些组件间的交互。它还包括一些决定，开发者希望这些决定能及早做出，因为在开发者看来它们是难以改变的。架构的主观性也体现在这里——如果你发现某些决定比你之前所认为的更容易改变，那么它就不再与架构相关。到了最后，架构自然就浓缩成一些重要的东西，不论这些东西是什么。

在本书中，我提出了一些自己的理解，涉及企业应用主要组成部分和我希望能尽早做对的决定。在这些架构模式中，我最欣赏的就是“层次”，将在第1章中进行详细介绍。全书实际上就是关于如何将企业应用分解成各个层次，以及这些层次之间如何协同工作。大多数重要的企业应用都使用某种形式的层次架构。当然，在某些情况下，别的方式（如管道方式、过滤器方式等）也有它们自己的价值。在本书中，我们将不会讨论这些方式，而把注意力集中在层次方式上，因为它是应用最广的设计方式。

本书中的一些模式毫无疑问是关于架构的，因为它们表示部件之间的重要决定；另外一些模式是关于设计的，有助于架构的实现。我没有刻意区分这两类模式，因为正如我们前面讨论的，是否与架构相关往往带有主观性。