企业应用架构模式
构建计算机系统并非易事。随着系统复杂性的增大，构建相应软件的难度将呈指数增大。我们只有在不断的学习中进步，从成功中学习经验，从失败中学习教训，才有望克服这些困难。这本书的内容通读之后，我认识到:只有通过模式的总结和学习，才能更有效地与他人进行交流。
关于模式。模式的概念早就有了，模式没有统一的定义。可能最好的起点是Christopher Alexander给出的定义：“每一个模式描述了一个在我们周围不断重复发生的问题以及该问题解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复劳动”[Alexander et al.]。尽管Alexander是建筑家，他谈论的是建筑模式，但其定义也能很好地适用于软件业。模式的核心就是特定的解决方案，它有效而且有足够的通用性，能解决重复出现的问题，模式的另一种视角是把它看成一组建议，而创造模式的艺术则是将很多建议分解开来，形成相互独立的组，在此基础上可以相对独立地讨论它们。模式的关键点是它们源于实践。必须观察人们的工作过程，发现其中好的设计，并找出“这些解决方案的核心”。这并不是一个简单的过程，但是一旦发现了某个模式，将是非常有价值的。你不必通读整本书的全部内容，也不必通读所有有关于模式的书。你只需要了解到这些模式都是干什么的，它们解决什么问题，它们是如何解决问题的，就足够了。这样，一旦碰到类似问题，就可以从书中找出相应的模式。那时，再深入了解相应的模式也不迟。一旦需要使用模式，就必须知道如何将它运用于当前的问题。使用模式的关键之一是不能盲目使用，因此你会多次看到同一解决方案，但没有一次是完全相同的。每个模式相对独立，但又不彼此孤立。有时候它们相互影响，如影随形。例如，如果在设计中使用了领域模型，那么经常还会用到类表继承。模式的边界本来也是模糊的。如果有人说“使用工作单元”，直接去看工作单元这个模式如何使用，而不必阅读全书。因此，撰写模式书籍的作者们也不会声称自己“发明”了某某模式，而是说“发现”了某某模式。对于一个高级设计师，模式的价值并不在于它给予我们一些新东西，而在于它能帮助我们更好地交流。如果你和你的伙伴都明白什么是远程外观，你们就可以这样非常简洁地交流大量信息：“这个类是一个远程外观模式。”也可以对新人说：“用数据传输对象模式来解决这个问题。”他们就可以查找本书来搞清楚如何做。模式为设计提供了一套词汇，这也是为什么模式的名字这么重要的原因。
关于模式的结构。每个作者都必须选择表达模式的形式，一些人采用的表达基于模式的一些经典教材如[Alexander et al.]、[Gang of Four]或[POSA]，另一些人用他们自己的方式。第一部分是模式的名字。模式名非常重要，因为模式的目的之一就是为设计者们交流提供一组词汇。接下来的两部分是相关的：意图和概要。意图用一两句话总结模式；概要是模式的一种可视化表示，通常是一个UML图。这主要是想给模式一个简单的概况，以帮助记忆。模式的动机可能不是该模式所能解决的唯一问题，但却是最具代表性的问题。“运行机制”部分描述了解决方案。为了便于理解，可以看UML图来辅助。“使用动机”部分描述了模式何时被使用。这部分讨论是选择该模式而不是其他模式的权衡考虑。本书中很多模式都可以相互替代，例如页面控制器和前端控制器可以相互替代。很少有什么模式是非它不可的。“进一步阅读”部分给出了与该模式相关的其他读物，它并不完善。为模式增加一个或几个例子，每个例子都非常简单，它们是用Java语言或C#语言编写的，但例子本身不是模式。当你使用模式时，不要想当然地认为它会和例子一样，也不要把例子看成某种形式的宏替换。当然，省略的部分并不是不重要，只是它们一般都特定于具体环境，这也是为什么模式在使用时一般都必须做适当调整的原因。为了使例子简单但是又能够突出核心意思，尽量选择那些简单而又明确的例子，而不是那些来自于系统中的复杂例子。当然，在简单和过分之间掌握平衡是不容易的，但是我们必须记住：过分强调具体应用环境反而会增加模式的复杂性，使得模式的核心内容不易理解。这就是为什么我在选择例子时选取的是一些相互独立的例子而不是相互关联的例子的原因。独立的例子有助于对模式的理解。但是在如何将这些模式联合在一起使用上却支持不多。相互关联的例子则相反，它体现了模式间是如何相互作用的，但是对其中每个模式的理解却依赖于对其他所有模式的理解。理论上，是可以构造出既相互关联又相互独立的例子，但这是一项非常艰巨的工作。例子中的代码本身也主要用来增强对思想的理解。因此，在其他一些方面考虑可能不够，特别是错误处理。在此，那些代码纯粹用来说明模式，而并不是用来显示如何对任何特定的业务问题进行建模。为了让那些基本的思想在应用设置下有所意义，本书的每个样例代码都充满着太多的“脚手架”来简化它们。
关于模式的局限性。对于企业应用开发而言，本书介绍的模式并不全面。模式这个领域太大了，单凭一个人的头脑是无法做到面面俱到的，更不用说是一本书了。本书中所列的模式都是在具体领域中能遇到的，但这并不表明已经理解了每一个模式以及它们之间的关系。对于软件开发而言，有一点是可以肯定的，那就是软件开发永远不会停止。使用模式时请记住：它们只是开始，而不是结束。任何作者去囊括项目开发中的所有变化和技术是不可能的，所有模式都是不完备的，我们都有责任在自己的系统中完善它们，我们也会在这个过程中得到乐趣。