《企業應用架構模式》
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給了我們優雅的設計方案，但它並不保證用這些方案能夠得到具有美感的架構設計，你仍然必須不斷地選擇、權衡。在這個領域裏，沒有銀彈。不然，還要我們程序員幹什麼？