Patterns of Enterprise Application Architecture《企业应用架构模式》Martin Fowler电力出版社2004年4月影印版
然而，上个星期我却只做了一件事：对一个项目的业务层代码进行重构，将它的体系结构设计从Transaction Script模式变成Domain Model模式。如果说软件开发者应该始终选择可行所有方案中的最简单者，如果说编程的唯一目的是实现业务需求，我的这一行为恐怕将无法解释。也许唯一合理的解释，只能是对惟美的偏爱了。
柏拉图认为万事万物都有一个完美的、先验的“理型”（eidos）存在，而我们眼见身受的事物无非是这理型的一个不完美的投影或者复制品―――就像用模子烤出来的蛋糕。如果我们愿意传承这位先贤的世界观，那么在我手边的这本Patterns of Enterprise Application Architecture（PoEAA）就多少有些像是柏拉图所设想的“理型的花园”了。如果要为这本PoEAA设计广告词的话，我会说它“承载了Martin Fowler之于企业级应用开发的思想精华”―――英文中的“idea”一词恰好源自希腊文的“eidos”，这也算是词源学的一次巧合吧。
MartinFowler在面向对象社群素有“教父”的美名―――我们当然还记得UML Distilled、Analysis Patterns和Refactoring。据说有位先生曾在一个技术研讨会的午餐时间与他的邻桌讨论OO技术，当他得知对方是Thought Works的员工时，立刻懊恼地说：“我竟然试图教Martin Fowler的同事OO技术，这简直就是木匠门前玩斧头、大江边上卖水了。”作为这个圈子里最著名的“传教士”，MartinFowler有一种常人所不及的归纳总结、提纲挈领的能力。很多“古已有之”的技术都是经过了他的点石成金，才真正在开发者的芸芸众生中流行起来―――重构技术就是一个最好的例子，而最近的例子则是Dependency Injection模式。
从他的作品中，我们可以明显地看出：Martin Fowler一直致力于为企业级应用开发者提供一套完备、自足的话语系统，一个理型的世界。Analysis Patterns告诉我们如何分析用户需求，Refactoring告诉我们如何改善代码质量，Planninge Xtreme Programming告诉我们如何规划敏捷的开发过程。这本PoEAA恰好是拼图的最后一块，它所记录的47个模式直指架构企业级应用时无法回避的那些问题。现在，Martin Fowler的信徒们可以完全用自己的一套话语来谈论企业级应用开发了。
面对这本PoEAA，或许不少读者会冒出这样一个念头：为什么我要使用这些模式？―――这个问题从前的版本是“为什么要重构”、“为什么要采用多层结构”，它们背后的潜台词是“为什么我要给自己增加这些麻烦”。实用主义的陈词滥调我们已经听得太多了：优雅的设计提升灵活性和复用性、使系统便于维护……噢，一边做着设计，一边还要考虑“这里是否需要灵活性”，我不认为自己有那么好的精力。在我看来，这里只有一个问题：系统是否呈现出一种内在的美。在我的系统中采用Transaction Script模式让我感到缺乏美感，所以我把它重构成Domain Model模式，这就是我的方式。
我提到了“美感”，这是一种形而上学吗？软件开发的全部艺术就是权衡：在简单与复杂之间权衡，在一种方案与另一种方案之间权衡。如果把每个问题、每个权衡的利弊都考虑得清清楚楚，恐怕开发一个应用程序的成本会高得惊人。所以，很多时候我们更依赖自己的审美眼光，用平静的心去设计一个赏心悦目的系统。缺乏美感的程序通常也同时缺乏质量，从前曾经流行的“万能JSP”就已经充分证明了这一点。这本PoEAA就像一幅画卷，它向我们展示了具有美感的架构方案。如果能暂时抛开实用主义的立场，用审美的眼光去浏览这幅画卷，或许能引起你更多的共鸣。
但是，请不要忘了，MartinFowler同时也是一位敏捷方法的鼓吹者。在他看来，过度设计、堆砌模式的系统同样是缺乏美感的。就像这本PoEAA，如果把这47个模式全部用在一个系统里，最终得到的只能是一堆臃肿不堪的垃圾。于是，我只好不时看看自己脚上的鞋子，在心里默念“KISS”、“YAGNI”，然后继续在完美与简单之间权衡。PoEAA给了我们优雅的设计方案，但它并不保证用这些方案能够得到具有美感的架构设计，你仍然必须不断地选择、权衡。在这个领域里，没有银弹。不然，还要我们程序员干什么？
 |
