Introduction

没有合适的体系结构就动手编程对于开发者来说是太平常不过的事。在没有明确的体系结构的情况下，大部分开发者或架构师都会依靠传统的体系结构模式（n层体系）把源码模块分成不同包(packages)来创造隐含层。不幸的是这种尝试往往会导致一个没有组织的源码模块集合，这些模块缺乏明确的角色，职责和模块之间的关系。这种现象通常称为反模式体系的大泥潭。

缺乏条理的体系结构的应用程序通常是耦合紧密的，不可靠的，难以改变和没有清晰的方向。所以说，在没有完全理解系统中组件和模块的内部工作原理就决定应用的架构特性是很困难的。关于调度和维护的基本问题是很难回答的：这个架构可以扩展吗？应用的性能特性是什么？应用有多容易改变？应用的调度特性是什么？这个架构怎么反应？

架构模式有助于定义基本的特性和应用的行为。比如，有些架构模式内在地适合高扩展的应用，而另一些架构模式适合高敏捷度的应用。知道每个架构模式的特性，优点和缺点是必须的，因为只有这样才能选出最适合你的具体的业务需求和目标。

作为一名架构师，你必须总能证明你的架构决定是对的，特别是到选择一个特定的架构模式。本文的目的就是给你足够的信息来做出架构的选择以及证明这个选择是正确的。