企業應用架構模式-30天閱讀計劃

構建計算機系統並不是易事。隨着系統複雜性的增大，構建相應軟件的難度將呈指數增大。

同其餘行業同樣，咱們只有在不斷的學習中進步，從成功經驗中學習，從失敗教訓中學習，纔有望克服這些困難。

這本書的內容就是這樣一些「學習」經驗。

只有經過模式的總結和學習，才能更有效地與他人進行交流。

—選自《企業應用架構模式》

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 模式的侷限性

正如我在前言中所述，對於企業應用開發而言，本書介紹的模式並不全面。我對本書的要求，不在於它是否全面，而在於它是否有用。模式這個領域太大了，單憑一我的的頭腦是沒法作到面面俱到的，更不用說是一本書了。

本書中所列的模式都是我在具體領域中遇到的，但這並不代表我已經理解了每個模式以及它們之間的關係。本書的內容只是反映了我在寫書時的理解，在編寫本書的過程當中，我對相關內容的理解也不斷髮展和加深，固然，在本書發表以後，我仍然但願本人對模式的理解還可以繼續發展。對於軟件開發而言，有一點是能夠確定的，那是軟件開發永遠不會中止。

當你使用模式時請記住：它們只是開始，而不是結束。任何做者去囊括項目開發中的全部變化和技術是不可能的。我編寫本書的目的也只是做爲一個開始，但願它可以把我本身的和我所瞭解的經驗和教訓傳遞給讀者，大家能夠在此基礎上繼續努力。請你們記住：全部模式都是不完備的，大家都有責任在本身的系統中完善它們，大家也會在這個過程當中獲得樂趣。

——選自：《企業應用架構模式》 [Patterns of Enterprise Application Architecture] [英] 福勒 著；王懷民，周斌 譯