有意思的應用程式很少能離群索居。無論是銷售系統要接庫存系統、採購系統要連上拍賣網站，或是 PDA 上的行事曆要跟公司行事曆伺服器同步——幾乎任何應用程式，只要跟別的應用程式整合起來，就會變得更好用。

整合的四項根本挑戰#

所有整合方案都得面對這幾件事：

• 網路不可靠——整合方案必須跨網路把資料從一台電腦搬到另一台。相較於單機行程，分散式運算要應付的問題多得多。待整合的兩套系統可能分處不同大陸，資料得穿過電話線、LAN 網段、路由器、交換器、公用網路與衛星鏈路，每一段都可能延遲或中斷。
• 網路很慢——跨網路送資料比本地方法呼叫慢上好幾個數量級。若用寫單一應用程式的思路去設計廣域分散的方案，效能後果會很慘烈。
• 任兩個應用程式都不一樣——整合方案必須在使用不同程式語言、作業平台、資料格式的系統之間傳遞資訊，因此得有能力介接所有這些技術。
• 改變無可避免——應用程式會隨時間演進，整合方案必須跟上。整合方案很容易陷入「改動雪崩」：一套系統一改，其他系統全部受影響。要避免這件事，就得靠**鬆散耦合（loose coupling）**把系統之間的相依性壓到最低。

四種整合途徑#

多年下來，開發者用四種主要作法來克服上述挑戰：

1. 檔案傳輸（File Transfer）——一個應用程式寫出檔案，另一個稍後讀取。雙方必須約定檔名與位置、檔案格式、讀寫時機，以及由誰刪檔。
2. 共享資料庫（Shared Database）——多個應用程式共用同一個實體資料庫中的同一套 schema。因為資料沒有重複儲存，就沒有資料要搬。
3. 遠端程序呼叫（Remote Procedure Invocation）——一個應用程式把部分功能開放成遠端程序，讓別的應用程式即時、同步地呼叫。
4. 訊息傳遞（Messaging）——一個應用程式把訊息發布到共同的訊息通道，其他應用程式稍後從通道讀取。雙方必須約定通道與訊息格式，通訊是非同步的。

四種作法解的本質上是同一個問題，但各有優劣。實務上一個應用程式可以同時使用多種風格，讓每個整合點都採用最適合它的那一種。

什麼是訊息傳遞？#

理解訊息傳遞最簡單的方式是想電話系統。打電話是同步通訊——只有對方當下有空，我才能跟他溝通。語音信箱則是非同步：對方沒接時，來電者可以留言，之後對方再挑自己方便的時間聽信箱裡排隊的留言。這比「想辦法讓兩個人同時在線上」容易太多了。語音信箱把（至少一部分的）通話包成一則訊息並排入佇列供日後取用——訊息傳遞本質上就是這麼運作的。

訊息傳遞是一種讓程式與程式之間能高速、非同步、可靠送達地通訊的技術：

• 程式之間互送稱為**訊息（message）**的資料封包
• 通道（channel），也叫佇列（queue），是連接程式、承載訊息的邏輯路徑。通道的行為像一個訊息的集合或陣列，只是它神奇地跨多台電腦共享，可被多個應用程式並行使用。
• **寄件者／生產者（sender / producer）**是把訊息寫進通道的程式；**收件者／消費者（receiver / consumer）**是從通道讀出（並刪除）訊息的程式。

訊息本身只是某種資料結構——字串、位元組陣列、記錄或物件。它可以被單純解讀為資料，也可以是「要在收件端執行的一道命令」的描述，或是「寄件端發生了某事件」的描述。

訊息由兩部分組成：表頭（header）與內文（body）。表頭放的是關於訊息本身的中介資訊——誰送的、要送去哪——由訊息系統使用，應用程式多半（但不總是）忽略它；內文放的是要傳輸的資料，訊息系統則不去碰它。開發者口中的「訊息」，通常指的是內文裡的資料。

非同步訊息架構很強大，但它要求我們重新思考開發方式。相較於另外三種整合途徑，接觸過訊息傳遞的開發者相對少，對這個通訊平台的慣用語與脾性也就不那麼熟悉。

什麼是訊息系統？#

訊息能力通常由一套獨立軟體提供，稱為訊息系統（messaging system）或訊息導向中介軟體（message-oriented middleware, MOM）。

訊息系統管理訊息的方式，就像資料庫系統管理資料持久化：管理員得先用 schema 把資料庫填好，同樣地，管理員也得先在訊息系統裡設定好通道，定義應用程式之間的通訊路徑，之後訊息系統才來協調與管理訊息的收發。資料庫的首要任務是確保每筆資料安全落地，訊息系統的首要任務則是可靠地把訊息從寄件端的電腦搬到收件端的電腦。

為什麼需要一套系統來搬訊息？因為電腦與連接它們的網路本質上不可靠。一端準備好要送，不代表另一端準備好要收；就算兩端都準備好了，網路也可能不通、或傳輸出錯。訊息系統的解法是反覆重試直到成功。

一則訊息的傳輸分為五步：

1. 建立（Create）——寄件端建立訊息並填入資料。
2. 送出（Send）——寄件端把訊息加入通道。
3. 遞送（Deliver）——訊息系統把訊息從寄件端電腦搬到收件端電腦，使其對收件端可見。
4. 接收（Receive）——收件端從通道讀出訊息。
5. 處理（Process）——收件端從訊息中取出資料。

這五步同時帶出兩個關鍵概念：

• 送出後就不管（Send and forget）——第 2 步完成後，寄件端就能去做別的事，傳輸由訊息系統在背景進行。寄件端可以確信收件端終究會收到，不必等在那裡。
• 儲存後轉送（Store and forward）——第 2 步時訊息系統會把訊息存在寄件端電腦（記憶體或磁碟）；第 3 步把它轉送到收件端電腦，並再次存起來。訊息在抵達收件端電腦前，這個「存了再轉」的過程可能重複很多次。

建立、送出、接收、處理這四步看似多餘——何不直接把資料交給收件端？關鍵在於：把資料包成訊息並存進訊息系統，等於把「送達的責任」委派出去。因為資料被包成原子性的訊息，遞送才能重試到成功，收件端也才能確保恰好收到一份。

為什麼要用訊息傳遞？#

簡答是：訊息傳遞比檔案傳輸即時，比共享資料庫封裝得好，比遠端程序呼叫可靠。但那只是起點。

具體好處包括：

• 遠端通訊——同一行程內的兩個物件可以直接共享記憶體中的資料；送到另一台電腦則複雜得多，物件必須可序列化。反過來說，若不需要遠端通訊，就不需要訊息傳遞——並行集合或共享記憶體這類更簡單的方案就夠了。
• 平台／語言整合——多套系統往往由獨立團隊在不同時期以不同語言與平台開發。整合它們常需要一整區中介軟體來斡旋，並退化到最小公分母（如格式難解的平面檔）。訊息系統則能扮演通用翻譯，讓每套系統各用各的語言與平台，卻透過共同的訊息典範溝通——這種普遍連通性正是**訊息匯流排（Message Bus）**的核心。
• 非同步通訊——寄件端不必等收件端收完、處理完，甚至不必等訊息系統送達；它只要等訊息成功存進通道即可。之後訊息在背景傳輸，寄件端可以去做別的事。若收件端要回傳確認或結果，就得再送一則訊息，並由寄件端以回呼機制偵測。
• 時序彈性——同步通訊下，呼叫端只能以收件端的處理速度發出呼叫。非同步則讓寄件端依自己的節奏批次送出請求、收件端依自己的節奏消化，兩邊都能跑在各自的最大吞吐量上。
• 節流（Throttling）——同時湧入太多遠端程序呼叫會壓垮收件端，造成效能劣化甚至崩潰。非同步讓收件端自行控制消化請求的速率；又因為通訊是非同步的，節流對呼叫端造成的影響也最小——它們並不會被阻塞。
• 可靠通訊——訊息傳遞之所以比 RPC 可靠，是因為採用「儲存後轉送」。資料被包成原子且獨立的訊息單元；寄件端送出時訊息系統先存起來，轉送到收件端電腦後再存一次。存在兩端電腦上這件事被視為可靠（要更可靠可存到磁碟，見保證送達（Guaranteed Delivery））；不可靠的是中間那段轉送，訊息系統就靠自動重送克服它。
• 離線運作——有些應用程式本來就設計成離線執行、有網路時再與伺服器同步（筆電、PDA、車載儀表）。訊息傳遞非常適合：待同步的資料一產生就排入佇列，等重新連上網再送。
• 中介（Mediation）——訊息系統扮演所有收發程式之間的中介者（Mediator，見 [GoF]）。應用程式可以拿它當作可整合的其他應用程式或服務的目錄；斷線後只需重新連上訊息系統，而不必逐一重連所有對象。訊息系統還能為共享資源（如資料庫）提供大量分散式連線，並以備援資源達成高可用、負載平衡、繞過故障鏈路，以及調校效能與服務品質。
• 執行緒管理——非同步意味著應用程式不必阻塞著等另一端完成工作。與其阻塞等待回覆，呼叫端可以用回呼在結果抵達時被通知（見請求－回覆（Request-Reply））。大量阻塞執行緒、或長時間阻塞，都是麻煩：可用執行緒可能被耗盡；而應用程式若在持有動態數量的阻塞執行緒時崩潰，重啟後要重建這些執行緒非常困難。改用回呼後，阻塞的只剩少數幾條已知的監聽執行緒，崩潰後也容易重建。

這些理由中，有些是開發者最有感的技術細節，有些則是最能打動企業架構師的策略決策。哪一項最重要，取決於你當下應用程式的實際需求。

非同步訊息傳遞的挑戰#

非同步訊息傳遞不是整合的萬靈丹。它優雅地解掉許多異質系統整合的難題，同時也帶來新的難題——有些源自非同步模型本身，有些則因訊息系統的實作而異。

• 程式模型變複雜——開發者必須改用事件驅動的模型。應用邏輯不再是一個方法呼叫另一個方法，而是被拆成一堆回應進站訊息的事件處理器；系統更複雜，也更難開發與除錯。舉例來說，一個簡單方法呼叫的等價物，可能需要請求訊息與請求通道、回覆訊息與回覆通道、關聯識別碼，以及一條無效訊息佇列（見請求－回覆）。
• 順序問題——通道保證訊息會送達，但不保證何時送達。這會讓依序送出的訊息亂序抵達；當訊息彼此相依時，必須另想辦法重建順序。
• 同步情境——不是所有應用程式都能「送出後就不管」。使用者在查機票時，想要的是立刻看到票價，而不是不知道多久之後。因此許多訊息系統必須架起同步與非同步之間的橋。
• 效能——訊息系統確實會增加通訊開銷。把資料做成訊息、送出、接收、處理，都要成本。若要搬一大塊資料，把它切成無數小片未必明智——例如兩套既有系統初次同步時的大批次資料複製，用 ETL（extract, transform, load）工具遠比訊息傳遞有效率；訊息傳遞最適合的是初次複製之後的持續同步。
• 平台支援有限——許多專有訊息系統並非在所有平台上都可用。有時候把檔案 FTP 到另一個平台，反而比透過訊息系統存取來得容易。
• 廠商鎖定——許多訊息系統實作依賴專有協定。即使是 JMS 這類共通規格，也不規範實體實作，因此不同訊息系統通常無法互連。這會給你一個全新的整合難題：整合多套整合方案（見訊息橋接（Messaging Bridge））。

非同步訊息傳遞不但沒有解決所有問題，還可能製造新問題。決定哪些問題要用訊息傳遞來解時，請把這些代價放在心上。

用非同步的方式思考#

大多數應用程式使用同步函式呼叫：程序呼叫子程序、方法呼叫方法，或透過 RPC（如 CORBA、DCOM）遠端呼叫。同步呼叫意味著呼叫端在子程序執行期間停住；即便是 RPC，呼叫端也得阻塞到子程序把控制權與結果交還。改用非同步訊息後，呼叫端「送出後就不管」，在子程序被喚起的同時繼續往下跑。

非同步通訊帶來三層影響：

1. 不再只有單一執行緒——多執行緒讓子程序能並行，可大幅提升效能，也確保某些子程序在別的子程序等待外部結果時仍能推進；但並行也讓除錯困難得多。
2. 結果透過回呼抵達——呼叫端能一邊做別的事一邊等通知，效能更好；但代價是它必須在做其他事的過程中有能力處理結果，並且能靠結果回想起「當初是在什麼脈絡下發出這個呼叫的」。
3. 子程序可以任意順序完成——這讓某個子程序能在另一個卡住時繼續推進；但也意味著子程序彼此必須能獨立、任意順序地執行，而呼叫端必須有辦法判斷哪個結果來自哪個子程序，並把結果組合起來。

分散式應用 vs. 整合#

本書談的是企業整合——如何讓獨立的應用程式協同工作。企業應用常採 n 層架構（client/server 的進階版），因而能分散在多台電腦上。即便這同樣造成不同機器上的行程互相通訊，那仍是應用程式分散，不是應用程式整合。

為什麼 n 層架構算分散而不算整合？

• 通訊的各方是緊密耦合的——彼此直接相依，少了其他層，某一層就無法運作。
• 各層之間的通訊傾向同步。
• 應用程式（無論 n 層或單體）通常有人類使用者，而人只接受快速的系統回應。

相對地，被整合的應用程式各自能獨立運行，只是以鬆散耦合的方式互相協調。這讓每個應用程式專注於一整套完整的功能，並把相關功能委派給其他應用程式。以非同步通訊的整合應用不必等待回應，可以先往下做或並行處理其他任務；它們的時間限制寬鬆得多，因此比「即時等結果的人類使用者」有耐心得多。

商業訊息系統#

非同步訊息整合的明顯效益，開闢了一塊可觀的中介軟體與工具市場。廠商產品大致可分四類：

1. 作業系統——訊息傳遞已是常見需求，廠商開始把必要的基礎設施做進作業系統或資料庫平台。例如 Windows 2000／XP 內含 MSMQ 服務，可透過 COM 元件與 .NET 的 System.Messaging 命名空間等多種 API 存取；Oracle 則把 Oracle AQ 納入資料庫平台。
2. 應用伺服器——Sun 在 J2EE 1.2 規格中納入 JMS，此後幾乎所有 J2EE 應用伺服器（IBM WebSphere、BEA WebLogic 等）都提供實作，Sun 也在 J2EE JDK 中附上參考實作。
3. EAI 套件——這類產品提供專有但功能豐富的整合套件，涵蓋訊息傳遞、商業流程自動化、工作流程、入口網站等。主要玩家有 IBM WebSphere MQ、Microsoft BizTalk、TIBCO、WebMethods、SeeBeyond、Vitria、CrossWorlds 等；另有 SonicSoftware、Fiorano 等廠商專注於實作相容 JMS 的訊息基礎設施。
4. Web Services 工具組——標準組織與聯盟正積極制定 Web service 上的可靠訊息遞送規格（WS-Reliability、WS-ReliableMessaging、ebMS），愈來愈多廠商提供以 Web service 為基礎的路由、轉換與管理工具。

本書的模式與廠商無關，適用於多數訊息方案。麻煩在於每家廠商都自訂術語，因此本書刻意挑選技術中立、產品中立，但描述性強、口語上好用的模式名稱。

模式的格式#

本書刻意採用接近 Alexandrian form 的寫法（Kent Beck 在《Smalltalk Best Practice Patterns》中率先把它引入程式設計領域）。這種格式讀起來更像散文：每個模式都遵循同一套結構，卻不為每個小節加標題，以免打斷論述的流動；改以粗體、縮排、圖片等版面元素幫讀者快速定位重點。

模式應該是**指示性（prescriptive）**的——它不只描述問題、不只描述怎麼解，而是告訴你該做什麼。每個模式代表讀者必須做的一個決策：「我該用訊息傳遞嗎？」「回覆訊息在這裡幫得上忙嗎？」

光是套用模式格式，不保證內容有料。要讓讀者真的從一個模式中學到東西，它必須說清楚為什麼這個問題難解、考慮那些看似可行但其實不行的方案，並解釋為何提出的解法是目前最好的；模式之間也必須互相牽引，把讀者從一個問題帶到下一個。

本書的模式結構如下：

• 名稱（Name）——標示這個模式在做什麼。名稱要能自然地放進句子裡，方便設計者之間口頭引用。
• 圖示（Icon）——多數模式配有圖示。因為許多架構師習慣用圖溝通，本書除了語彙語言外也提供視覺語言；多個圖示可以組合起來描述更大、更複雜的解法，凸顯模式的可組合性。
• 脈絡（Context）——說明你在做什麼樣的工作時，會遇上這個模式所解的問題。脈絡替問題鋪陳舞台，也常提及你可能已套用的其他模式。
• 問題（Problem）——以「你正在問自己的一個問句」表達你面對的困難。讀完問題敘述就該能快速判斷這個模式與你的工作是否相關。格式為一句話、粗體、縮排。
• 作用力（Forces）——探討那些讓問題難解的限制。若問題很容易，就不需要模式了。這裡常會考慮那些看似有希望、實際卻行不通的替代方案，藉此凸顯真正解法的價值。
• 解法（Solution）——一個模板，說明該怎麼解決問題。它不針對你的特定情境，而是描述在問題所涵蓋的各種情境下該怎麼做。只要理解了問題與解法，就理解了這個模式，其餘章節不一定要讀。格式同樣是一句話、粗體、縮排。
• 草圖（Sketch）——Alexandrian form 最迷人的特性之一，就是每個模式都配一張說明解法的草圖。很多時候光看名稱與草圖就能抓到模式的精髓。
• 結果（Results）——展開解法，說明實際套用的細節、它如何化解各種作用力，以及套用後可能浮現的新挑戰。
• 接下來（Next）——列出套用本模式後該接著考慮哪些模式。模式不會孤立存在，套用一個模式通常會引出新問題，而新問題由其他模式來解——這正是「模式語言」而非「模式目錄」的關鍵。
• 邊欄（Sidebars）——討論更細的技術議題或模式的變體，視覺上與正文分開，讓你能在不相關時安心跳過。
• 範例（Examples）——模式的實際應用案例，可能只是點名一個已知用法，也可能是一大段程式碼。考慮到訊息技術種類繁多，本書刻意設計成跳過範例也不會漏掉模式的關鍵內容。

圖表符號#

整合方案由許多不同零件組成——應用程式、資料庫、端點、通道、訊息、路由器……要描述它就需要一套涵蓋這些元件的符號。

UML 很擅長用類別圖與互動圖描述物件導向系統，但缺乏描述訊息方案的語意；UML Profile for EAI [UMLEAI] 雖然擴充了協作圖的語意來描述元件間的訊息流，本書仍決定不採用，理由有二：

• 該 Profile 無法涵蓋本書模式語言中的所有模式。
• 本書要的不是精確的視覺規格（可用於 MDA 程式碼生成），而是帶有**「草圖」質感**的圖——能讓讀者一眼抓到模式精髓，就像 Alexander 的草圖那樣。

因此本書自創了一套簡單的符號：訊息透過通道送往元件。這裡的「元件」用得很寬鬆——可以是被整合的應用程式、轉換或路由訊息的中介者，或是應用程式的某個特定部分。想強調通道本身時畫成立體管線，比較在意元件時就把通道畫成帶箭頭的線，兩種畫法等價。訊息則畫成一棵小樹：圓形的根加上層層方形元素；樹的元素可以上色或加網底，凸顯它在特定模式中的角色。這種畫法特別適合描述轉換類模式——新增、重排、移除欄位一目了然。

描述應用程式設計時（例如訊息端點，或以 C#／Java 撰寫的範例），本書仍使用標準的 UML 類別圖與循序圖。

範例與間奏#

本書刻意用多種整合技術寫範例，來凸顯模式的廣泛適用性。缺點是你未必熟悉每一種技術——因此本書確保讀範例完全是選擇性的，所有重點都已在模式描述中交代；能提供多種技術實作時，本書也盡量提供不只一種。

範例程式碼的取捨如下：

• 可讀性優先於可執行性。程式碼片段能消除解法敘述可能留下的模糊，而且許多開發者與架構師寧可看 30 行程式碼，也不想讀好幾段文字。
• 通常只列出較大方案中最相關的方法或類別，並省略大部分錯誤檢查，以凸顯核心功能。
• 多數片段不放行內註解，因為前後段落已有說明。

所有程式範例都只是教學用的示意，不該當作實際整合方案的起點——它們幾乎都缺少錯誤檢查，也未考慮強健性、安全性與可擴展性。

為單一整合模式提供有意義的範例並不容易：企業整合方案通常由散布在多套系統上的異質元件組成，而多數整合模式也不是孤立運作，得靠其他模式一起才構成有意義的方案。因此本書在各大段落的結尾安排了間奏（interlude），用更完整的範例展現多個模式如何協作，以及設計較完整方案時的種種取捨。

本書範例盡量建立在免費或有試用版的平台上；部分情況使用商業平台（如 TIBCO ActiveEnterprise、Microsoft BizTalk），以對比「從零打造」與「用商業工具」的差異，並確保即使你沒有那套執行環境也讀得懂。至於 JMS、MSMQ 這類較陽春的框架，好處是能把焦點留在問題本身，不被複雜中介軟體的一堆功能分散注意力。

• Java 範例基於 JMS 1.1（J2EE 1.4 的一部分）
• .NET 範例基於 .NET Framework 1.1，以 C# 撰寫

本書的組織方式#

模式語言是一張互相指涉的網，但有些模式比其他模式更根本，形成從大概念到細節的層級。這些大概念模式是整套語言的承重結構，本書稱之為根模式（root patterns）。

最根本的模式是 Messaging——那正是整本書在談的東西。它引出六個根模式（收錄於「訊息系統」一章）：Message Channel、Message、Pipes and Filters、Message Router、Message Translator、Message Endpoint。除了 Pipes and Filters（它並非訊息專屬，而是路由與轉換模式的基礎）之外，每個根模式都各自展開成書中的一章。

模式語言依此層級分成八章：

• 整合風格（Integration Styles）——回顧可用的各種應用整合途徑，包含 Messaging。
• 訊息系統（Messaging Systems）——回顧六個根模式，給出整套模式語言的概觀。
• 訊息通道（Messaging Channels）——通道定義訊息可走的邏輯路徑，本章教你判斷需要哪些通道。
• 訊息建構（Message Construction）——有了通道之後就需要訊息，本章說明訊息的各種用法與特殊屬性。
• 訊息路由（Message Routing）——當拓樸變複雜，寄件端愈來愈不知道誰該收到訊息，於是把訊息交給中介應用程式接力轉送。本章講這些路由元件的職責。
• 訊息轉換（Message Transformation）——獨立開發的應用程式常在格式、識別碼的形式與意義、甚至字元編碼上談不攏，因此需要中介元件做轉換。本章講怎麼設計它們。
• 訊息端點（Messaging Endpoints）——許多應用程式當初就沒打算參與訊息方案，必須被明確地接上訊息系統。本章描述應用程式內負責收發訊息的那一層。
• 系統管理（System Management）——訊息系統上線後，怎麼確認它跑得正確、做的是我們要它做的事？本章談如何測試與監控。

如何開始讀#

從頭到尾讀完能確保覆蓋整個主題，卻不是最快找到解答的方式；從語言中段切入又像看一部演到一半的電影——看得到畫面，卻不知道意義何在。

幸運的是，模式語言是圍繞根模式成形的。根模式集合起來就是整套語言的概觀，個別來看又是深入細節的入口。

想快速掃過整套語言而不讀完所有模式，就先讀根模式；想從中段切入，就挑一個根模式當入口——那正是語言結束一個大主題、開始下一個的接縫處。

本書的根模式有：

• Messaging——全書的第一號根模式：什麼是訊息傳遞、它解什麼問題、怎麼解？
• Message Channel——訊息系統中把訊息從寄件端送到收件端的結構是什麼？怎麼知道應用程式需要哪些？
• Message——資訊如何從寄件端傳達到收件端？
• Pipes and Filters——訊息送出之後、被接收之前，如何插入中間步驟？
• Message Router——若寄件端不知道訊息最終該去哪，訊息系統要如何把它送到？
• Message Translator——若收發雙方對訊息格式沒有共識，它們如何溝通？
• Message Endpoint——收發訊息的應用程式如何接上訊息系統？

讀完前兩章後，不同角色可依需求選讀：

• 系統管理員——「訊息通道」（該建哪些通道）與「系統管理」（如何維運）。
• 應用開發者——「訊息端點」（如何把應用程式接上訊息系統）與「訊息建構」（何時該送什麼訊息）。
• 系統整合人員——「訊息路由」（如何把訊息導向正確的接收者）與「訊息轉換」（如何在格式之間轉換）。

趕時間時，讀一個模式只要先看粗體的問題與解法兩句話，就足以判斷這個模式現在對你有沒有用、你是不是早就懂了。有興趣再讀其餘部分。

也請記得：這是一套模式語言，模式不必按書中順序讀。書的順序是為了教學而把相關議題排在一起討論；要解特定問題時，應該從合適的根模式出發，順著它的「脈絡」找出該先套用的模式、順著結尾的「接下來」找出該接續的模式——用互相連結的模式網，而不是線性的頁碼順序來引導你。

小結#

讀完本章，你應該掌握了以下基礎概念：

• 什麼是訊息傳遞、什麼是訊息系統、為什麼要用它
• 非同步程式設計有何不同
• 應用整合與應用分散的差別
• 哪些類型的商業產品內含訊息系統

以及本書將如何教你使用訊息傳遞：

• 模式在組織素材上扮演的角色
• 圖表所用自訂符號的意義
• 範例的目的與範圍
• 素材的組織方式與入門路徑