—選自《企業應用架構模式》
目 錄
1引言
構建計算機系統並非易事。隨着系統復雜性的增大，構建相應軟件的難度將呈指數增大。同其他行業一樣，我們只有在不斷的學習中進步，從成功經驗中學習，從失敗教訓中學習，才有望克服這些困難。本書的內容就是這樣一些“學習”經驗。我希望它們的撰寫和編排方式，能夠有助於讀者更快地學習這些內容，並且，和我在總結出這些模式之前相比，能更有效地與他人進行交流。
在引用中，我想設定本書討論的范圍，並提供一些相關的背景知識與材料。
0.1 架構
軟件業的人樂於做這樣的事——找一些詞匯，並把它們引申到大量微妙而又互相矛盾的含義。一個最大的受害者就是“架構”（architecture）這個詞。我個人對“架構”的感覺是，它是一個讓人印象深刻的詞，主要用來表示一些非常重要的東西。當然，我也會小心，不讓這些對“系統結構”的“不恭之詞”，影響到讀者對本書的興趣。
很多人都試圖給“架構”下定義，而這些定義本身卻很難統一。能夠統一的內容有兩點：一點是“最高層次的系統分解”；另一點是“系統中不易改變的決定”。越來越多的人發現：表述一個系統架構的方法不只一種；一個系統中也可能有很多種不同的架構，而且，對於什么在架構上意義重大的看法也會隨着系統的生命周期變化。
Ralph Johnson經常在郵件列表上發帖，並提出一些令人關注的見解。就在我完成本書初稿的同時，他又發表了一些關於“架構”的觀點。他認為，架構是一種主觀上的東西，是專家級項目開發人員對系統設計的一些可共享的理解。一般地，這種可共享的理解表現為系統中主要的組成部分以及這些組成間的交互關系。它還包括一些決定，開發者們希望這些決定能及早做出，因為在開發者看來它們是難以改變的。架構的主觀性也來源於此——如果你發現某些決定並不像你想象的那么難以改變，那么它就不再與架構相關。到了最后，架構自然就濃縮成一些重要的東西，不論這些東西是什么。
在本書中，我提出一些自己的理解，涉及企業應用主要組成部分和我希望能盡早做出的決定。在這些架構模式中，我最欣賞的就是“層次”，將在第1章中進行詳細介紹。全書實際上就是關於如何將企業應用組織成不同的層次，以及這些層次之間如何協同工作。大多數重要的企業應用都是按照某種形式的層次分層設計的；當然，在某些情況下，別的設計方式（如管道方式、過濾器方式等）也有它們自己的價值。在本書中我們將不會討論這些方式，而把注意力集中在層次方式上，因為它是應用最廣的設計方式。
本書中的一些模式毫無疑問是關於架構的，它們表示了企業應用各主要組成部分間的重要決定；另外一些模式是關於設計的，有助於架構的實現。我沒有刻意區分這兩類模式，因為正如我們前面討論的，是否與架構相關往往帶有主觀性。
0.2 企業應用
編寫計算機軟件的人很多，我們通常把這些活動都稱為軟件開發。但是軟件的種類是不同的，每種軟件都有自身的挑戰性和復雜性。我是在與幾個從事電信軟件開發的朋友交談后，意識到這個問題的。企業應用在某些方面要比電信軟件簡單得多——多線程問題沒有那么困難，無需關注硬件設備與軟件的集成。但是，在某些方面，企業應用又比電信軟件復雜得多——企業應用一般都涉及到大量復雜數據，而且必須處理很多“不合邏輯”的業務規則。雖然有些模式是適合所有軟件的，但是大多數模式都還只適合某些特定的領域和分支。
我的工作主要是關於企業應用的，因此，這里所談及的模式也都是關於企業應用的。（企業應用還有一些其他的說法，如“信息系統”或更早期的“數據處理”。）那么，這里的“企業應用”具體指的是什么呢？我無法給出一個精確的定義，但是我可以羅列一些個人的理解。
先舉幾個例子。企業應用包括工資單、患者記錄、發貨跟蹤、成本分析、信譽評估、保險、供應鏈、記賬、客戶服務以及外幣交易等。企業應用不包括車輛加油、文字處理、電梯控制、化工廠控制器、電話交換機、操作系統、編譯器以及電子游戲等。
企業應用一般都涉及到持久化數據。數據必須持久化是因為程序的多次運行都需要用到它們——實際上，有些數據需要持久化若干年。在此期間，操作這些數據的程序往往會有很多變化。這些數據的生命周期往往比最初生成它們的那些硬件、操作系統和編譯器還要長。在此期間，數據本身的結構一般也會被擴展，使得它在不影響已有信息的基礎上，還能表示更多新信息。即使是有根本性的變化發生，或公司安裝了一套全新的軟件，這些數據也必須被“遷移”到這些全新的應用上。
企業應用一般都涉及到大量數據——一個中等規模的系統往往都包含1GB以上的數據，這些數據是以百萬條記錄的方式存在的。巨大的數據量導致數據的管理成為系統的主要工作。早期的系統使用的是索引文件系統，如IBM的VSAM和ISAM。現代的系統往往采用數據庫，絕大多數是關系型數據庫。數據庫的設計和演化已使其本身成為新的技術領域。
企業應用一般還涉及到很多人同時訪問數據。對於很多系統來說，人數可能在100人以下，但是對於一些基於Web的系統，人數會呈指數級增長。要確保這些人都能夠正確地訪問數據，就一定會存在這樣或那樣的問題。即使人數沒有那么多，要確保兩個人在同時操作同一數據項時不出現錯誤，也是存在問題的。事務管理工具可以處理這個問題，但是它通常無法做到對應用開發者透明。
企業應用還涉及到大量操作數據的用戶界面屏幕。有幾百個用戶界面是不足為奇的。用戶使用頻率的差異很大，他們也經常沒什么技術背景。因此，為了不同的使用目的，數據需要很多種表現形式。系統一般都有很多批處理過程，當專注於強調用戶交互的用例時，這些批處理過程很容易被忽視。
企業應用很少獨立存在，通常需要與散布在企業周圍的其他企業應用集成。這些各式各樣的系統是在不同時期，采用不同技術構建的，甚至連協作機制都不同：COBOL數據文件、CORBA系統或是消息系統。企業經常希望能用一種統一的通信技術來集成所有系統。當然，每次這樣的集成工作幾乎都很難真正實現，所有留下來的就是一個個風格各異的集成環境。當商業用戶需要同其業務伙伴進行應用集成時，情況就更糟糕。
即使是某個企業統一了集成技術，它們也還是會遇到業務過程中的差異以及數據中概念的不一致性。一個部分可能認為客戶是當前簽有協議的人；而另外一個部門可能還要將那些以前有合同，但現在已經沒有了的人計算在內。再有，一個部門可能只關心產品銷售而不關心服務銷售。粗看起來，這些問題似乎容易解決，但是，一旦幾百個記錄中的每個字段都有可能存在着細微差別，問題的規模就會形成不小的挑戰——就算唯一知道這些字段之間差別的員工還在公司任職（當然，也許他在你察覺到之前就早已辭職不干了）。這樣，數據就必須被不停地讀取、合並、然后寫成各種不同語法和語義的格式。
再接下來的問題是由“業務邏輯”帶來的。我認為“業務邏輯”這個詞很滑稽，因為很難找出什么東西比“業務邏輯”更加沒有邏輯。當我們構建一個操作系統時，總是盡可能地使得系統中的各種事物符合邏輯。而業務邏輯生來就是那樣的，沒有相當的行政努力，不要想改變它，當然，它們都有自己的理由。你必須面對很多奇怪的條件。而且這些條件相互作用的方式也非常怪異。比如，某個銷售人員為了簽下其客戶幾百萬美元的一張單，可能會在商務談判中與對方達成協議，將該項目的年度到賬時間推遲兩天，因為這樣才能與該客戶的賬務周期相吻合。成千上萬的這類“一次特殊情況”最終導致了復雜的業務“無邏輯”，使得商業軟件開發那么困難。在這種情況下，必須盡量將這些業務邏輯組織成有效的方式，因為我們可以確定的是，這些“邏輯”一定會隨着時間不斷變化。
對於一些人來說，“企業應用”這個詞指的是大型系統。但是 需要注意的是，並不是所有的企業應用都是大型的，盡管它們可能都為企業提供巨大的價值。很多人認為，由於小型系統的規模不大，可以不用太注意它們，而且在某種程度上，這種觀點能夠帶來一定的成本節約。如果一個小型系統失敗了，相對於大型系統的失敗，這種失敗就不會顯得那么起眼了。但是，我認為這種思想沒有對小型項目的累積作用給予足夠的重視。試想，如果在小型項目上能夠進行某些改善措施，那么一旦這些改善措施被成功運用於大型項目，它帶來的效果就會非常大。實際上，最好是通過簡化架構和過程，將一個大型項目簡化成小型項目。
0.3 企業應用的種類
在我們討論如何設計企業應用以及使用哪些模式之前，明確這樣一個觀點是非常重要的，即企業應用是多種多樣的，不同的問題將導致不同的處理方法。如果有人說“總是這樣做” 的時候，就應該敲響警鍾了。我認為，設計中最具挑戰性（也是我最感興趣）的地方就是了解有哪些候選的設計方法以及各種不同設計方法之間的優劣比較。進行選擇的控件很大，但我在這里只選三個方面。
考慮一個B2C（Business to Customer）的網上零售商：人們通過瀏覽器瀏覽，通過購物車購買商品。通過購物車購買商品。這樣一個系統必須能夠應付大量的客戶，因此，其解決方案不但要考慮到資源利用的有效性，還要考慮到系統的可伸縮性，以便在用戶規模增大時能夠通過增加硬件的辦法加以解決。該系統的業務邏輯可以非常簡單：獲取訂單，進行簡單的價格計算和發貨計算，給出發貨信息。我們希望任何人都能夠訪問該系統，因此用戶界面可以選用通用的Web表現方式，以支持各種不同的瀏覽器。數據源包括用來存放訂單的數據庫，還可能包括某種與庫存系統的通信交流，以便獲得商品的可用性信息和發貨信息。
再考慮一個租約合同自動處理系統。在某些方面，這樣的系統比起前面介紹的B2C系統要簡單，因為它的用戶數很少（在特定時間內不會超過100個），但是它的業務邏輯卻比較復雜。計算每個租約的月供，處理如提早解約和延遲付款這樣的事件，簽訂合同時驗證各種數據，這些都是非常復雜的任務，因為租約領域的許多競爭都是以過去的交易為基礎稍加變化而出現的。正是因為規則的隨意性很大，才使得像這樣一個復雜領域具有挑戰性。
這樣的系統在用戶界面（UI）上也很復雜。這就要求HTML界面要能提供更豐富的功能和更復雜的屏幕，而這些要求往往是HTML界面目前無法達到的，需要更常規的胖客戶界面。用戶交互的復雜性還會帶來事務行為的復雜性：簽訂租約可能要耗時1~2個小時，這期間用戶要處於一個邏輯事務中。一個復雜的數據庫設計方案中可能也會涉及到200多個表以及一些有關資產評估和計價的軟件包。
第三個例子是一家小型公司使用的簡單的“開支跟蹤系統”。這個系統的用戶很少，功能簡單，通過HTML表現方式可以很容易實現，涉及的數據源表項也不多。盡管如此，開發這樣的系統也不是沒有挑戰。一方面你必須快速地開發出它，另一方面你又必須為它以后可能的發展考慮；也許以后會為它增加賠償校驗的功能，也許它會被集成到工資系統中，也許還要增加關於稅務的功能，也許要為公司的CFO生成匯總報表，也許會被集成到一個航空訂票Web Service中，等等。如果在這個系統的開發中，也試圖使用前面兩個例子中的一些架構，可能會影響開發進度。如果一個系統會帶來業務效益（如所有的企業應用應該的那樣），則系統進度延誤同樣也是開銷。如果現在不做決策又有可能影響系統未來的發展。但是，如果現在就考慮了這些靈活性但是考慮不得當，額外的復雜性又可能會影響到系統的發展，進一步延誤系統部署，減少系統的效益。雖然這類系統很小，但是一個企業中往往有很多這樣的系統，這些系統的架構不良性累積起來，后果將會非常可怕。
這三個企業應用的例子都有難點，而且難點各不相同。當然，也不可能有一個適合於三者的通用架構。選擇架構時，必須很清楚地了解面臨的問題，在理解的基礎上再來選擇合適的設計。本書中也沒有一個通用的解決方案。實際上，很多模式僅僅是一些可選方案罷了。即使你選擇了某種模式，也需要進一步根據面臨的問題來修改模式。在構建企業應用時，你不思考是不行的。所有書本知識只是給你提供信息，作為你做決定的基礎。
模式是這樣，工具也同樣如此。在系統開發時應該選取盡可能少的工具，同時也要注意，不同的工具擅長處理的方面也不同，切記不要用錯了工具，否則只會事倍功半。
0.4 關於性能的考慮
很多架構的設計決策和性能有關。對於大多數與性能相關的問題，我的辦法是首先建立系統，調試運行，然后通過基於測量的嚴格的優化過程來提高性能。但是，有一些架構上的決策對性能的影響，可能是后期優化難以彌補的。而且即使這種影響可以在后期很容易地彌補，參與這個項目的人們任然會從一開始就擔心這些決策。
在這樣的一本書中討論性能通常很困難。這是因為“眼見為實”：所有那些關於性能的條條框框，不在你的具體系統中配置運行一下，是很難有說服力的。我也經常看到一些設計方案因為性能方面的考慮而被接受或拒絕，但是一旦有人在真實的設置環境中做一些測量，就會證明這些考慮是錯誤的。
本書將提出一些這方面的建議，包括盡量減少遠程調用（它在很長時間內都被認為是優化性能的好建議）。盡管如此，還是建議讀者在運用這些原則之前，在你的應用中具體試一試。同樣，本書中的樣例代碼也有一些地方為了提高可讀性而犧牲了效率。在你的系統中，需要自行決定是否進行優化。在做性能優化后，一定要與優化前進行測量對比，以確定真的得到了優化，否則，你可能只是破壞了代碼的可讀性。
還有一個很重要的推論：配置上的重大變化會使得某些性能優化失效。因此，在升級虛擬機、硬件、數據庫或其他東西到新的版本時，必須重新確認性能優化工作的有效性。很多情況下，配置變更都會對性能優化有影響，有時候你真的會發現，以前為了提升性能做的優化，在新環境下居然影響性能。
關於性能的另一個問題是很多術語的使用不一致。最明顯的例子就是“可伸縮性”（scalability），它可能有6-7種含義。下面我使用其中一些術語。
響應時間是系統完成一次外部請求處理所需要的時間。這些外部請求可能是用戶交互行為，例如按下一個按鈕，或是服務器API調用。
響應性不同於請求處理，它是系統響應請求的速度有多快。這個指標在許多系統里非常重要，因為對於一些系統而言，如果其響應性太慢，用戶將難以忍受——盡管其響應時間可能不慢。如果在請求處理期間，系統一直處於等待狀態，則系統的響應性和響應時間是相同的。然而，如果能夠在處理真正完成之前就給用戶一些信息表明系統已經接到請求，則響應性就會好一些。例如，在文件拷貝過程中，為用戶提供一個“進度條”，將會提高用戶界面的響應性，但並不會提高響應時間。
等待時間是獲得系統任何形式響應的最小時間，即使應該做的工作並不存在。通常它是遠程系統中的大問題。假設我們讓程序什么都不做，只是調用返回即可，則如果在本機上運行程序，一般都會立即得到響應。但是，如果在遠程計算機上運行程序，情況就不一樣，往往需要數秒的時間才能得到響應。因為從發出請求到得到響應的數秒時間主要用於排除使信息在線路上傳輸的困難。作為應用開發者，我經常對等待時間無能為力。這也是為什么要盡量避免遠程調用的原因。
吞吐率是給定時間內能夠處理多大的請求量。如果考察的是文件拷貝，則吞吐率可以用每秒字節量來表示。對於企業應用來說，吞吐率通常用每秒事務數（tps）來度量。這種方法的一個問題是指標依賴於事務的復雜程度。對於特定系統的測試，應該選取普通的事務集合。
在這里，性能或指吞吐率，或者指響應時間，由用戶自己決定。當通過某種優化技術后，使得系統的吞吐率提高了，但是響應時間下降了，這時就不好說系統的性能提高了，最好用更准確的術語表示。從用戶角度而言，響應性往往比響應時間更重要，因此，為了提高響應性而損失一些響應時間或者吞吐率是值得的。
負載是關於系統當前負荷的表述，也許可以用當前有多少用戶與系統相連來表示。負載有時也作為其他指標（如響應時間）的背景。因此，我們可以說：在10個用戶的情況下，請求響應時間是0.5秒，在20個用戶的情況下，請求響應時間是2秒。
負載敏感度是指響應時間隨負載變化的程度。假設：系統A在10~20個用戶的情況下，請求響應時間都是0.5秒；系統B在10個用戶的情況下，請求響應時間是0.2秒，在20個用戶的情況下，請求響應時間上升到2秒。此時，系統A的負載敏感度比系統B低；我們還可以使用術語衰減（degradation），稱系統B衰減得比系統A快。
效率是性能除以資源。如果一個雙CPU系統的性能是30tps，另一個系統有4個同樣的CPU，性能是40tps，則前者效率高於后者。
系統的容量是指最大有效負載或吞吐率的指標。它可以是一個絕對最大值或性能衰減至低於一個可接受的閾值之前的臨界點。
可伸縮性度量的是向系統中增加資源（通常是硬件）對系統性能的影響。一個可伸縮性的系統允許在增加了硬件后，能夠有性能上的合理提高。例如，為了使吞吐率提高一倍，要增加多少服務器等。垂直可伸縮性或稱垂直延展，通常指提高單個服務器的性能，例如增加內存。水平可伸縮性或稱水平延展，通常指增加服務器的數目。
問題是，設計決策對所有性能指標的作用並不相同。比如，某個服務器上運行着兩個軟件系統：Swordfish的容量是20tps，而Camel的容量是40tps。哪一個的性能更高？哪一個的可伸縮性好？僅憑這些數據，我們無法回答關於可伸縮性的問題，我們只能說Camel系統在單片機上的效率更高。假設又增加了一台服務器后，我們發現：Swordfish的容量是35tps，Camel的容量是50tps。盡管Camel的容量仍然大於Swordfish，但是后者在可伸縮性上卻顯得比前者更好。假設我們繼續增加服務器數目后發現：Swordfish每增加一台服務器提高15tps，Camel每增加一台服務器提高10tps。在獲得了這些數據后，我們才可以說，Swordfish的水平可伸縮性比Camel好，盡管Camel在5個服務器以下會有更好的效率。
當構建企業應用系統時，關注硬件的可伸縮性往往比關注容量或效率更重要。如果需要，可伸縮性可以給予你獲得更好性能的選擇，可伸縮性也可以更容易實現。有時，設計人員費了九牛二虎之力才提高了少許容量，其開銷還不如多買一些硬件。換句話說，假設Camel的費用比Swordfish高，高出的部分正好可以買幾台服務器，那么選擇Swordfish可能更合算，盡管你目前只需要40tps。現在人們經常抱怨軟件對硬件的依賴性越來越大，有時為了運行某些軟件就不得不對硬件進行升級，就像我一樣，為了用最新版本的Word，就必須不斷地升級筆記本電腦。但是總的來說，購買新硬件還是比修改舊軟件來得便宜。同樣，增加更多的服務器也比增加更多的程序員來得便宜——只要你的系統有足夠的可伸縮性。
0.5 模式
模式的概念早就有了。我在這里不想把這段歷史重新演繹一遍。只是想簡單談談我對模式和它們為什么是描述設計的重要手段的一些看法。
模式沒有統一的定義。可能最好的起點是Christopher Alexander給出的定義（這也是許多模式狂熱者的靈感來源）：“每一個模式描述了一個在我們周圍不斷重復發生的問題以及該問題解決方案的核心。這樣，你就能一次又一次地使用該方案而不必做重復勞動”[Alexander et al.]。盡管Alexander是建築家，他談論的是建築模式，但其定義也能很好地適用於軟件業。模式的核心就是特定的解決方案，它有效而且有足夠的通用性，能解決重復出現的問題，模式的另一種視角是把它看成一組建議，而創造模式的藝術則是將很多建議分解開來，形成相互獨立的組，在此基礎上可以相對獨立地討論它們。
模式的關鍵點是它們源於實踐。必須觀察人們的工作過程，發現其中好的設計，並找出“這些解決方案的核心”。這並不是一個簡單的過程，但是一旦發現了某個模式，他將是非常有價值的。對於我來說，價值之一是能夠撰寫這樣一本參考書。你不必通讀本書的全部內容，也不必通讀所有有關於模式的書。你只需要了解到這些模式都是干什么的，它們解決什么問題，它們是如何解決問題的，就足夠了。這樣，一旦碰到類似問題，就可以從書中找出相應的模式。那時，再深入了解相應的模式也不遲。
一旦需要使用模式，就必須知道如何將它運用於當前的問題。使用模式的關鍵之一是不能盲目使用，這也是模式工具為什么都那么慘的原因。我認為模式是一種“半生不熟品”，為了用好它，還必須在自己的項目中把剩下的那一半“火候”補上。我本人每次在使用模式時，都會東改一點西改一點。因此你會多次看到同一解決方案，但沒有一次是完全相同的。
每個模式相對獨立，但又不彼此孤立。有時候它們相互影響，如影隨形。例如，如果在設計中使用了領域模型，那么經常還會用到類表繼承。模式的邊界本來也是模糊的，我在本書中也盡量讓它們各自獨立。如果有人說“使用工作單元”，你就可以直接去看工作單元這個模式如何使用，而不必閱讀全書。
如果你是一個有經驗的企業應用設計師，也許會對大多數模式都很熟悉。希望本書不會給你帶來太大的失望。（實際上我在前言里面已經提醒過了。）模式不是什么新鮮概念。因此，撰寫模式書籍的作者們也不會聲稱我們“發明”了某某模式，而是說我們“發現”了某某模式。我們的職責是記錄通用的解決方案，找出其核心，並把最終的模式記錄下來。對於一個高級設計師，模式的價值並不在於它給予你一些新東西，而在於它能幫助你更好地交流。如果你和你的同事都明白什么是遠程外觀，你就可以這樣非常簡潔地交流大量信息：“這個類是一個遠程外觀模式。”也可以對新人說：“用數據傳輸對象模式來解決這個問題。”他們就可以查找本書來搞清楚如何做。模式為設計提供了一套詞匯，這也是為什么模式的名字這么重要的原因。
本書的大多數模式是用來解決企業應用的，基本模式一章（見第18章）則更通用一些。我把它們包含進來的原因是：在前面的討論中，我引用了這些通用的模式。
0.5.1 模式的結構
每個作者都必須選擇表達模式的形式。一些人采用的表達基於模式的一些經典教材如[Alexander et al.]、[Gang of Four]或[POSA]。另一些人用他們自己的方式。我在這個問題上也斟酌了很久。一方面我不想象GOF一樣太精煉，另一方面我還要引用他們的東西。這就形成了本書的模式結構。
第一部分是模式的名字。模式名非常重要，因為模式的目的之一就是為設計者們交流提供一組詞匯。因此，如果我告訴你Web服務器是用前端控制器和轉換試圖構建的，而你又了解這些模式，那么你對我的Web服務器的架構就會非常清楚了。
接下來的兩部分是相關的：意圖和概要。意圖用一兩句話總結模式；概要是模式的一種可視化表示，通常是（但不總是）一個UML圖。這主要是想給模式一個簡單的概況，以幫助記憶。如果你對模式已經“心知肚明”，只是不知道它的名字，那么模式的意圖和概要這兩部分就能為你提供足夠的信息。
接下來的部分描述了模式的動機。這可能不是該模式所能解決的唯一問題，但卻是我認為最具代表性的問題。
“運行機制”部分描述了解決方案。在這一部分，我會討論一些實現問題以及我遇到的變化情況。我會盡可能獨立於平台來討論——也有一個部分是針對平台來討論的，如果不感興趣可以跳過這部分。為了便於解釋，我用了一些UML圖來輔助說明。
“使用動機”部分描述了模式何時被使用。這部分討論是使我選擇該模式而不是其他模式的權衡考慮。本書中很多模式都可以相互替代，例如頁面控制器和前端控制器可以相互替代。很少有什么模式是非它不可的。因此，每當我選擇了一種模式之后，我總是問自己“你什么時候不用它？”這個問題也經常驅使我選擇其他方案。
“進一步閱讀”部分給出了與該模式相關的其他讀物。它並不完善。我只選擇我認為有助於理解模式的參考文獻，所以我去掉了對本書內容沒有價值的任何討論，當然其中也可能會遺漏一些我不知道的模式。我也沒有提到一些我認為可能讀者無法找到的參考文獻，再就是一些不太穩定的Web鏈接。
我喜歡為模式增加一個或幾個例子。每個例子都非常簡單，它們是用Java語言或C#語言編寫的。我之所以選擇兩種語言，是因為它們可能是目前絕大多數專業程序員都能讀懂的語言。必須注意，例子本身不是模式。當你使用模式時，不要想當然地認為它會和例子一樣，也不要把例子看成某種形式的宏替換。我把例子編得盡量簡單以突出其中模式相關的部分。當然，省略的部分並不是不重要，只是它們一般都特定於具體環境，這也是為什么模式在使用時一般都必須做適當調整的原因。
為了盡量使例子簡單但是又能夠突出核心意思，我主要選擇那些簡單而又明確的例子，而不是那些來自於系統中的復雜例子。當然，在簡單和過分之間掌握平衡是不容易的，但是我們必須記住：過分強調具體應用環境反而會增加模式的復雜性，使得模式的核心內容不易理解。
這就是為什么我在選擇例子時選取的是一些相互獨立的例子而不是相互關聯的例子的原因。獨立的例子有助於對模式的理解。但是在如何將這些模式聯合在一起使用上卻支持不多。相互關聯的例子則相反，它體現了模式間是如何相互作用的，但是對其中每個模式的理解卻依賴於對其他所有模式的理解。理論上，是可以構造出既相互關聯又相互獨立的例子，但這是一項非常艱巨的工作——至少對於我來說是這樣。因此，我選擇了相互獨立的例子。
例子中的代碼本身也主要用來增強對思想的理解。因此，在其他一些方面考慮可能不夠——特別是錯誤處理，在這方面，我沒有花費很多筆墨，因為到目前為止，我還沒有得出錯誤處理方面的模式。在此，那些代碼純粹用來說明模式，而並不是用來顯示如何對任何特定的業務問題進行建模。
正是由於這些原因，我沒有把這些代碼放到我的網站上供大家下載。為了讓那些基本的思想在應用設置下有所意義，本書的每個樣例代碼都充滿着太多的“腳手架”來簡化它們。
並不是每個模式中都包含上面所述的各個部分。如果我不能想出很好的例子或動機等內容，我就會把相應部分省略。
0.5.2 模式的局限性
正如我在前言中所述，對於企業應用開發而言，本書介紹的模式並不全面。我對本書的要求，不在於它是否全面，而在於它是否有用。模式這個領域太大了，單憑一個人的頭腦是無法做到面面俱到的，更不用說是一本書了。
本書中所列的模式都是我在具體領域中遇到的，但這並不表明我已經理解了每一個模式以及它們之間的關系。本書的內容只是反映了我在寫書時的理解，在編寫本書的過程中，我對相關內容的理解也不斷發展和加深，當然，在本書發表之后，我仍然希望本人對模式的理解還能夠繼續發展。對於軟件開發而言，有一點是可以肯定的，那是軟件開發永遠不會停止。
當你使用模式時請記住：它們只是開始，而不是結束。任何作者去囊括項目開發中的所有變化和技術是不可能的。我編寫本書的目的也只是作為一個開始，希望它能夠把我自己的和我所了解的經驗和教訓傳遞給讀者，你們可以在此基礎上繼續努力。請大家記住：所有模式都是不完備的，你們都有責任在自己的系統中完善它們，你們也會在這個過程中得到樂趣。
第1章 分層
在分解復雜的軟件系統時，軟件設計者用得最多的技術之一就是分層。在計算機本身的架構中，可以看到：到處都有分層的例子：不同的層從包含了操作系統調用的程序設計語言，到設備驅動程序和CPU指令集，再到芯片內部的各種邏輯門。網絡互聯中， FTP層架構在TCP之上， TCP架構在IP之上， IP又架構在以太網之上。
當用分層的觀點來考慮系統時，可以將各個子系統想像成按照“多層蛋糕”的形式來組織，每一層都依托在其下層之上。在這種組織方式下，上層使用了下層定義的各種服務，而下層對上層一無所知。另外，每一層對自己的上層隱藏其下層的細節。因此，第4層使用第3層的服務，第3層使用第2層的服務，第4層無需知道第2層的細節。（當然，並非所有的分層架構都這么隔絕，但絕大多數是不透明的，或至少是幾乎不透明的。）
將系統按照層次分解有很多重要的好處：
• 在無需過多了解其他層次的基礎上，可以將某一層作為一個有機整體來理解。例如，無需知道以太網的工作細節，你照樣可以在TCP上構建FTP服務。
• 可以替換某層的具體實現，只要前后提供的服務相同即可。例如， FTP服務無論是在以太網、 PPP上、還是網絡運營商使用的任何網絡上都無需改變，而且與提供傳輸電纜的網絡
運營商無關。
• 可以將層次間的依賴性減到最低。假設網絡運營商改變了物理傳輸系統，但只要IP層不變，FTP服務就可以不改變。
• 分層有利於標准化工作。 TCP和IP就是關於它們各自層次如何工作的標准。
• 一旦構建好了某一層次，就可以用它為很多上層服務提供支持。因此， TCP/IP同時被FTP、telnet、 SSH和HTTP使用。否則，所有這些高層協議都必須編寫它們各自的底層協議。分層是一種重要的技術，但也有缺陷：
• 層次並不能封裝所有東西。有時它會為我們帶來級聯修改。最經典的例子就是在一個分層設計的企業應用中，如果要增加一個在用戶界面上顯示的數據域，就必須在數據庫中增加相應的字段，還必須在用戶界面和數據庫之間的每一層做相應的修改。
• 過多的層次會影響性能。在每一層，一般都會從一種表現形式轉換到另一種。不過底層功能的封裝通常帶來比代價更大的效率提升。例如，可以優化事務控制層，提高其他各層的效率。
然而，分層架構中最困難的問題是決定建立哪些層次以及每一層的職責是什么。
1.1 企業應用中層次的演化
我雖然沒有從事過早期批處理系統時期的任何工作，但我認為當時的軟件工作人員不會太
關注層次的概念，只要編寫操作某些文件（ ISAM、 VSAM等）格式的程序，這就是當時的應用。
它不需要層次。
20世紀90年代，隨着客戶/服務器系統的出現，分層的概念更明顯了。這樣的系統是一種兩
個層次的系統：客戶端包括用戶界面和其他應用代碼，服務器端通常是關系型數據庫。常見的
客戶端工具如VB、 PowerBuilder和Delphi。這些工具使得構建數據密集型應用非常容易。因為
它們的用戶界面控件通常都是SQL感知的。因此，可以通過將控件拖拽到“設計區域”來建立
界面，然后再使用屬性表單把控件連接到后台數據庫。
如果應用僅僅包括關系數據的簡單顯示和修改，那么這種客戶/服務器系統的工作方式非常
合適。問題來自領域邏輯：如業務規則、驗證、計算等。通常，人們會把它們寫在客戶端，但
是這樣很笨拙，並且往往把領域邏輯直接嵌入到用戶界面。隨着領域邏輯的不斷復雜化，這些
代碼將越來越難以使用。而且，這樣做很容易產生冗余代碼，這意味着簡單的變化都會導致要
在很多界面中尋找相似代碼。
另外一種辦法是把這些領域邏輯放到數據庫端，作為存儲過程。但是，存儲過程只提供有
限的結構化機制，這將再次導致笨拙的代碼。而且，很多人喜歡關系型數據庫的原因之一是
SQL是一個標准，允許他們更換數據庫廠商。盡管真正更換數據庫廠商的用戶寥寥無幾，但還
是有很多人希望擁有這種選擇，並且沒有太大的附加代價。由於存儲過程都是數據庫廠商私有
的，因此普通用戶被剝奪了這種選擇權。
在客戶/服務器方式逐漸大眾化的同時，面向對象方式開始崛起。面向對象為領域邏輯的問
題找到了答案：轉到三層架構的系統。在這種方式下，在表現層實現用戶界面，在領域層實現
領域邏輯，在數據源層存取數據。這種方式使你可以將復雜的領域邏輯從界面代碼中抽取出來，
單獨放到中間層，用對象加以建模和組織。
盡管有這些優勢，但一開始面向對象的進展並不大。當時的實際情況是：大多數系統並不
特別復雜，或者至少在構建之初沒有那么復雜。因此，當系統比較簡單時，相對於三層架構的
優勢，強有力的客戶/服務器工具的競爭力非常大。但客戶/服務器工具很難甚至無法應用於三層
架構系統的配置。
我認為真正巨大的沖擊來自Web的興起。人們忽然想在Web瀏覽器上部署這些客戶/服務器
應用。然而，如果所有的領域邏輯都是寫在“胖”客戶中，則所有這些都必須在Web界面中重寫。
對於設計良好的三層系統來說，只需要增加一個新的表現層，就可以了。另外， Java的出現使得
面向對象語言無所顧忌地向當時的主流技術發起沖擊。用於構建Web頁面的工具對SQL的綁定也
沒有那么緊密了，這也使得它們比較容易適應三層結構。
當人們討論分層時，常常不容易區分layer和tier。這兩個詞匯經常被用作同義詞，但是很多
人還是認為tier意味着物理上的分離。客戶/服務器系統常常被稱為“two-tier system”，其分離是
物理上的分離：客戶端是一台台式機，而服務器端是一台服務器。我使用layer，旨在強調無需
把不同的層次放在不同的計算機上運行。獨立出來的領域邏輯層，既可以運行在台式計算機上，
也可以運行在數據庫服務器上。在這種情形下，有兩個節點，但是有三個層次。如果數據庫也
在本地，還可以在一台筆記本電腦上運行三層軟件，當然，仍舊存在三個截然不同的層次。
1.2 三個基本層次
本書主要就三個基本層次的架構展開討論：表現層、領域層和數據源層（這里的命名取自
文獻[Brown et al.]）。表1-1總結了這些層次。
表1-1 三個基本層次
層 次 職 責
表現層 提提供服務，顯示信息（例如在Windows或HTML頁面中，處理
用戶請求（鼠標點擊，鍵盤敲擊等）， HTTP請求，命令行調用，
批處理API）
領域層 提邏輯，系統中真正的核心
數據源層 提與數據庫、消息系統、事務管理器及其他軟件包通信
表現邏輯處理用戶與軟件間的交互。可能簡單到只是命令行或基於文本的菜單系統，但是
當前的客戶界面往往是功能完善的胖客戶圖形界面，或者是基於HTML的瀏覽器界面（本書中的
“胖客戶”是指Windows/Swing/fat-client用戶界面，不包括HTML瀏覽器）。表現層的主要職責是
向用戶顯示信息並把從用戶那里獲取的信息解釋成領域層或數據源層上的各種動作。
數據源邏輯主要關注與其他系統的交互，這些系統將代表應用完成相關的任務。它們可以
是事務監控器、其他應用、消息系統等。對於大多數企業應用來說，最主要的數據源邏輯就是
數據庫，它的主要責任是存儲持久數據。
最后一部分就是領域邏輯，也稱為業務邏輯。它就是應用必須做的所有領域相關工作：包
括根據輸入數據或已有數據進行計算，對從表現層輸入的數據進行驗證，以及根據從表現層接
收的命令來確定應該調度哪些數據源邏輯。
有時，層次組織成領域層對表現層完全隱藏了數據源層。但更多的時候，是表現層直接對
數據存儲進行操作。雖然這樣做並不純粹，但是在實踐中往往運行良好。表現層可能解釋來自
用戶的命令，通過數據源層將相關數據從數據庫中提取出來，然后讓領域邏輯層在向用戶顯示
相關數據之前先處理這些相關數據。
一個單獨的企業應用，可能在上述的三個層次上都包含多個軟件包。如果某個應用不僅要
支持用戶通過胖客戶機界面訪問，還要支持用戶通過命令行形式訪問，則它需要兩個表現層：
一個支持胖客戶機界面，另一個支持命令行。對於不同的數據庫，通常也需要多個數據源組件，
特別是在與已有的軟件包通信時。即便是領域邏輯，也有可能被分割成相互獨立的不同部分，
特定的數據源包只能由特定的領域包使用。
到目前為止，我們一直都在討論用戶。這很自然地會引出一個問題：如果驅動軟件的不是
人，情況又怎么樣呢？比如說驅動者可能是時髦的Web Service或是一個老土但實用的批處理程
序。對於后者，用戶將是一個客戶程序。這樣，很明顯，表現層就有可能與數據源層出現某些
相似之處，因為它們都是系統與外界的接口。這就是Alistair Cockburn的Hexagonal Architecture
模式[wiki]背后的邏輯，它將任何系統都視為由到外部系統的接口所圍繞的一個核心。在
Hexagonal Architecture中，所有外部的東西都被視為外部接口。因此，從這種意義上說，它是一
種對稱視圖，而不是本書中的非對稱分層視圖。
然而，我認為這種非對稱性是有益的。因為，為別人提供服務的接口與使用別人服務的接
口存在較大的差別，需要明確區分。這就是表現層和數據源層相對於核心的本質差別。表現層
是系統對外提供服務的外部接口，不管外面是復雜的人類還是一個簡單的遠端程序。數據源層
是系統使用外部服務的接口。這樣區分的好處是：客戶的不同將改變你對服務的看法。
對每個企業應用，盡管我們能夠區分出其中的主要的表現層、領域層和數據源層，但是具
體如何分離要取決於應用的復雜程度。 從數據庫中讀取數據並把它顯示在Web頁面上的簡單腳本，
可能全部在一個過程中。我將仍然盡量保持三層架構的風格，不過在這里可能只是把每個層的
行為放到三個不同的子程序中。一旦系統再復雜一點，就可以將三個層次的工作分解成不同的
類。如果復雜度繼續增加，則把類分配到不同的包中。我的總體建議就是根據不同的問題，選
擇一種適合的分離方式，但是切記一定要進行某種形式的分離—至少在子程序級別。
伴隨着分離，還有一條關於依賴性的普遍原則：領域層和數據源層絕對不要依賴於表現層。
也就是說，在領域層和數據源層的代碼中，不要出現調用表現層代碼的情況。這條規則將簡化
在相同的基礎上替換表現層的代價，也使得表現層的修改所帶來的連鎖反應盡可能小。領域層
與數據源層的關系更復雜，其取決於數據源層的架構模式。
使用領域邏輯時，其中一個最困難的部分就是區分什么是領域邏輯，什么是其他邏輯。一
種不太正規的測試辦法就是：假想向系統中增加一個完全不同的新層，例如為Web應用增加一個
命令行界面層。如果在這個過程中，發現需要重復實現某些功能，則說明可能有一些本應該在
領域層實現的邏輯，現在在表現層實現了。類似地，你也可以假想一下，將后台數據庫更換成
XML文件格式，看看情況又會如何？
舉一個例子。我所知道的一個系統有一張產品列表，其中，當月銷售量比上月銷售量大10％
的產品需要用紅色顯示。為實現這個功能，開發者在表現層邏輯中比較當月和上月的銷售量，
然后將差別大於10％的產品顯示為紅色。
這樣做的麻煩就是將領域邏輯放到了表現層中。為了進行適當的分離，需要在領域層中定
義一個方法，用來指示該產品的銷售量是否較上月有較大提高。該方法完成銷售量的比較，返
回一個布爾值。表現層則只需要簡單地調用一下這個布爾方法，如果返回值為真，則用紅色突
出顯示這個產品。這樣，該過程就分解成兩部分：確定需不需要突出顯示，選擇如何突出顯示。
當然，我擔心這樣也許有些太教條主義了。 Alan Knight在審閱本書時評論說：他自己“很
頭大，將部分領域邏輯混入表現層到底是滑向地獄的第一步呢，還是只有少數純粹主義者才會
抱怨的小問題？”我們之所以擔心，正是因為這種做法兩者兼備。
1.3 為各層選擇運行環境
本書絕大多數篇幅討論的都是邏輯層次—將系統中各部分分離，以降低不同部分之間的
耦合程度。即使是都運行在同一台計算機上，不同層次間的分離也是非常重要的。當然，系統
物理結構的不同會有所影響。
對於大多數信息系統來說，主要的決定就是在哪里運行處理工作，是在客戶機上，還是在
台式機上，又或是在服務器上？
通常，最簡單的情況是將所有東西都運行在服務器上。在這種情況下，一個使用Web瀏覽器
的HTML前端是一個好方法。這樣做最大的好處是所有的東西都在有限的環境內，很容易修改維
護。無需考慮將它們分發到不同的客戶端並維護與服務器的同步等問題。也不必考慮與客戶機
上其他軟件的兼容性問題。
在客戶機上運行應用程序的好處是系統的響應性好，或者在網絡斷開的情況下也能正常工
作。任何運行在服務器上的邏輯在響應客戶請求時，都需要一個來回的通信開銷。如果用戶僅
僅是為了試試系統的即時反饋，這個通信來回也無法避免。它還需要在網絡連接保持的狀態下
運行。當然，網絡的分布可能會無所不在，但是至少在我寫本書的時候， 31000英尺高的地方還
沒有。也許在不久的將來，就會到處都有了，但有不少人需要立即工作，不必等待網絡連接。
斷接操作帶來特別的挑戰性，我不想在本書中過多討論。
有了這些約束，我們就可以逐層分析了。數據源層一般都是運行在服務器上。例外情況是：
當需要斷接操作時，可以將服務器的功能復制到一台功能強大的客戶機上。在這種情況下，在
離線的客戶機上對數據源的任何修改，都需要同步到服務器上。正如我前面提到的那樣，關於
這方面的討論，我想留到以后某個時候或留給另一位作者。
在何處運行表現層主要取決於用戶界面的種類。如果運行的是一個胖客戶，則意味着表現
層運行在客戶端。如果運行的是一個Web界面，則意味着表現層運行在服務器端。當然，也有例
外—例如，客戶軟件（如Unix中的X servers）的遠程操作在台式機上運行了一個Web服務器—當
然，這是極少數情況。
如果要建立一個B2C系統，就沒什么選擇了。無論是誰都可能訪問你的服務器，你也不想因
為客戶用的是TRS-80系統，就把他拒之門外。在這種情況下，可以在服務器上完成所有工作，
並提供一個HTML界面給瀏覽器。這樣做的缺點就是每個操作都必須要一個來回的通信開銷，可
能會影響響應時間。可以通過可下載的applet或瀏覽器腳本來緩解問題，但是它們同時會帶來瀏
覽器兼容性等其他問題。使用的HTML越純粹，事情就會變得越簡單。
即使你們的每一台台式機都是由你們公司的信息系統部門手工精心搭建的，這種簡單性仍
然非常誘人。因為即使是非常簡單的胖客戶系統，也會遇到維護客戶端一致性以及避免各種軟
件不兼容等問題。
人們希望有胖客戶表現層的主要原因是：有些任務對於用戶而言太復雜了，為了有一個可
用的應用系統，它們的需要超出了Web GUI的能力。當然，人們已經在逐漸習慣於采用使Web前
端更可用的各種方法，這些方法減少了對胖客戶方式的需求。因此，我非常贊同只要有可能就
用Web表現方式，只有在必需的情況下才使用胖客戶方式。
剩下來的就是領域邏輯了。領域邏輯可以全都運行於服務器端，也可以全都運行於客戶端，
也可以一分為二。再有，全部運行在服務器端有助於系統維護，向客戶端轉移是為了響應時間
及斷接使用的需要。
如果你必須在客戶端運行某種邏輯，可以考慮將所有邏輯都運行在客戶端—這樣至少保
證了相關的東西都在一起。這樣，胖客戶端和Web服務器聯合部署在客戶機上，對響應性的改善
不會太大，但是它可以作為一種處理斷接操作的辦法。在這種情況下，可以通過不同的模塊將
領域邏輯與表現層分開，可以使用事務腳本或領域模型。將所有的領域邏輯放在客戶端的問題
是升級和維護代價高。
將領域邏輯分割在客戶端和服務器端，應該是最差的選擇，因為這樣做無法確定任意一塊
邏輯到底在哪。采用這種方式的主要原因是：只有一小部分領域邏輯需要在客戶端完成。其中
的訣竅就是將這一小部分獨立出來成為自包含的模塊，使得它不依賴於系統的任意其他部分。
這樣，就可以在客戶端或服務器端運行它了。這將需要采用一些煩人的小技巧，但它的確是一
個解決問題的好辦法。
一旦選擇了處理節點，接下來就應該盡可能使所有代碼保持在單一進程內完成（可能是在
同一個節點上，也可能拷貝在集群中的多個節點上）。除非不得已，否則不要把層次放在多個進
程中完成。因為那樣做不但損失性能，而且增加復雜性，因為必須增加類似下面的模式，如遠
程外觀和數據傳輸對象。
以下因素被Jens Coldewey稱為復雜性增壓器（ complexity booster）：分布、顯式多線程、范
型差異（例如對象/關系）、多平台開發以及極限性能要求（如每秒100個事務以上）。所有這些因
素都會帶來很大的代價。當然，有時我們無法回避它們，但是要切記：這里羅列的每一項都會
為開發和運行維護階段帶來開銷。
——選自：《企業應用架構模式》 [Patterns of Enterprise Application Architecture] [英] 福勒 著；王懷民，周斌 譯