Martin Fowler談企業級軟體架構模式

在1999年春天，我飛抵芝加哥為ThoughtWorks公司正在開發的一個專案擔任顧問。ThoughtWorks是一個規模雖小但正在快速成長的應用程式開發公司。這個專案是一個後端租賃系統，屬於那種極具挑戰性的企業級應用程式。簡單來說，它處理的是客戶簽字承租之後所有與租賃相關的商業行為，像是寄送帳單、處理某些租客對租賃資產的改造、追蹤那些遲繳帳單的租客，以及處理某位租客提前歸還資產等情形。在你意識到租賃合約是高度複雜且總是在不斷變化之前，上述情況聽起來好像不會太難處理。但它的商業「邏輯」幾乎不能套用任何現有的邏輯模式，畢竟這些合約內容是商人們為了獲取生意所制定的，合約條款中一些古怪的調整變動，都可能成為贏得某筆交易的關鍵。因此，每次交易的小勝利也都意味著增加系統的複雜性。

這類事情總讓我興奮不已：如何設計一個可以追蹤並處理高度複雜問題的物件導向系統。事實上，物件導向最大的優點在於它能使複雜的邏輯易於管理。為複雜的商業邏輯開發一個好的Domain Model（領域模型），其過程是非常困難的，但結果會是非常令人滿足。

當然，事情並非僅僅是開發領域模型這麼簡單。我們的領域模型必須要能持續保留到資料庫中，而像過去許多專案一樣，我們使用的是關聯式資料庫。我們必須將這個模型連結到使用者介面，還要支援遠端應用程式使用我們的軟體，以及整合我們的軟體與第三方軟體。上述工作都基於一種叫做J2EE的新技術，在當時，這是全世界尚未有人實戰應用過的技術。

雖然J2EE是一項嶄新的技術，我們仍然能夠從以往的經驗中得到幫助。我曾經使用C++、Smalltalk和CORBA來開發系統。ThoughtWorks公司中則有許多人有Forte方面的經驗。當時我們已經有了關鍵基礎架構，只需要搞清楚如何將它應用在J2EE上。現在回過頭來看三年前的設計，雖然不盡完善，但已經可以說是通過時間的考驗了。

上述情況正是我撰寫這本書的出發點。多年來我看過許多企業級專案，這些專案通常都包含相似的設計思路，也已經被證明可以有效地處理企業級應用程式中不可避免的複雜性。這本書的目的，就是將這些設計思路轉化為模式的一個起點。

這是一本有關企業級應用程式設計的書籍。企業級應用程式涉及大量複雜資料的顯示、操作和儲存，以及對這些資料進行商業流程自動化。典型的範例有預約系統、財務系統、供應鏈系統及其他驅動現代商業運作的系統。企業級應用系統不同於嵌入式系統、控制系統、電信系統及桌面應用軟體，它們有自己特有的挑戰及解決方案。

在建置企業級應用程式時會遇到許多架構問題。本書很難一一詳細列舉。本書討論的主要議題為：

● 企業級應用程式的分層

● 建構領域（商業）邏輯

● 建構Web使用者介面

● 將記憶體模組（特別是物件）連結到關聯式資料庫

● 在無狀態環境下處理工作階段（session）狀態

● 分散式原則

這本書並不打算針對任何特定的軟體平台。我在20世紀的80年代末期和90年代初期使用Smalltalk、C++和CORBA的時候第一次遇到這些模式。在90年代後期，我開始使用Java進行大量的工作，發現這些模式很好地適用於早期的Java/CORBA系統和後來基於J2EE的工作。最近，我一直在使用Microsoft的.NET平台進行一些初步工作，發現這些模式再次適用。我的ThoughtWorks同事也分享了他們的經驗，尤其是在Forte方面。我不能聲稱這些模式在所有（曾經或即將）被用於開發「企業級應用程式」的平台上都是通用的，但目前為止，這些模式已顯示出足夠的可重覆使用性。

我為大多數的模式提供了範例程式碼。我選擇的程式語言是我認為大多數讀者都可以閱讀和理解的語言。Java在這裡是一個不錯的選擇。任何能閱讀C或C++的人都可以閱讀Java，但Java遠不如C++複雜。基本上，大多數的C++程式設計人員都可以閱讀Java，但反之則不然。我是一位物件信徒，所以我不可避免地傾向於物件導向語言（OO language）。因此，大多數的程式碼範例都是用Java撰寫的。在我寫書當下，Microsoft的.NET環境逐漸成熟，對於作者來說，它的C#語言與Java擁有許多相同的屬性。因此，我也用C#做了一些程式碼範例，儘管這會帶來一些風險，因為開發人員在.NET方面經驗尚且不足，它使用的術語可能還未形成慣例。它們兩者都是基於C語言，因此，如果你可以閱讀其中一種語言，你應該能同時讀懂這兩種語言，即使你並不熟悉另一種語言或平台。我的目標是使用一種讓最多軟體開發人員能夠閱讀的語言，即使它不是他們主要或首選的語言。（我要向喜歡Smalltalk、Delphi、Visual Basic、Perl、Python、Ruby、COBOL或其他語言的讀者道歉。我知道你們認為有一種比Java或C#更好的語言，我也認為如此！）

這些範例是為了啟發和解釋模式中的想法。它們並不是能直接使用的解決方案；任何情況下，你都需要做大量的工作才能將它們融入你的應用程式之中。模式只是一個好的開始，但它們並不是終點。

目標讀者

我的目標讀者是那些正在建置企業級應用程式，並希望加強對架構問題的理解和溝通的程式開發人員、設計人員與架構師。

我假設我的大多數讀者歸為兩類：一些人有適度的需求並希望建置自己的軟體，另一些人則有大規模的需求，並且將使用某個工具。對於那些有適度需求的人，我的意圖是，這些模式應該讓你有一個好的起點。在許多領域，你需要的不僅僅是模式所能提供的，我將在本書提供一個比我當初進入此領域時更高的起點。對於工具的使用者，我希望這本書能讓你瞭解幕後發生的事情，也幫助你選擇哪一種工具適合哪一種模式使用。例如，使用O/R Mapping工具同時意味著你必須決定如何對應（map）某些情境。閱讀這些模式應該可以為你提供一些做出選擇的指引。

由於模式是將反覆出現的問題，淬鍊成通用的解決方案，因此，你很有可能已經遇過其中的一些情境。如果你已經在企業級應用程式中工作了一段時間，那麼你可能對其中的大部分模式瞭若指掌。我不是要聲稱本書中有任何新的內容；事實上，我想聲稱的恰恰相反，這是一本（關於我們軟體產業）舊調重彈的書籍。

如果你是這一領域的新手，我希望本書能幫助你瞭解這些技術。如果你熟悉這些技術，我希望本書能幫助你與他人交流和傳授它們。模式的一個重要作用是嘗試建置一個共通的詞彙，例如，你可以說這個類別是一個Remote Facade（遠端外觀），其他的設計人員會懂你想表達的意思。（本文摘錄整理自《Martin Fowler的企業級軟體架構模式》作者序，博碩文化提供）

 書名  Martin Fowler的企業級軟體架構模式：軟體重構教父傳授51個模式，活用設計思考與架構決策

Martin Fowler／著；陳傳興、張立顗／譯

博碩文化出版

售價：800元

 作者簡介 

Martin Fowler

Martin Fowler是ThoughtWorks公司的首席科學家（ThoughtWorks是專業的企業級軟體開發與系統整合公司）。早在1980年代，他就是率先使用物件技術建置多分層企業級應用程式的領航者。他也是多本經典名著的作者，包括《Analysis Patterns》、《UML Distilled》、《Planning Extreme Programming》和《Refactoring》等等，以上書籍由Addison-Wesley出版。他的個人網站：www.martinfowler.com。