在投入時間學習這些模式之前，合理的問題是：「為什麼？」設計模式與實踐究竟能如何改變我們設計與建構軟體的方式？作者提出三個理由。

站在巨人的肩膀上#

• 我們解決的問題、建構的系統極少是真正獨一無二的——拼裝出的組合與軟體支撐的商業模式或許前所未見，但系統的建構方式、以及追求可靠、敏捷、可擴展時遇到的問題，並不新鮮。
• 模式的第一個價值：讓我們從別人的錯誤中學習。與其指望同事恰好有經驗、或自己重蹈他人覆轍，不如以模式為嚮導。
• 學習分散式系統的模式，跟學習任何程式設計最佳實踐一樣——它加速你建構軟體的能力，而不要求你親身經歷那些促成模式成形的系統、錯誤與第一手教訓。

討論實務的共同語言#

• 模式對已經精通它們的資深分散式系統開發者仍然有價值：模式提供共享詞彙（shared vocabulary），讓我們能快速理解彼此，而這種理解是知識分享與進一步學習的基礎。
• 想像我們用同一種物件蓋房子，我叫它「Foo」、你叫它「Bar」——我們會浪費多少時間爭論 Foo 與 Bar 的優劣，才發現講的是同一個東西？
• 沒有共同詞彙，時間就耗在「激烈同意」（violent agreement）的爭論、或解釋對方其實懂只是名稱不同的概念上。模式提供共同的名稱與定義，讓討論直接切入核心概念的細節與實作。

作者在容器領域親眼見證了這件事：當 Sidecar 容器的概念（見第二章）在容器社群扎根後，大家不再需要花時間定義什麼是 Sidecar，而能立刻跳到「如何用這個概念解決眼前的問題」——「我們用個 Sidecar 就好」「對，而且我知道有現成的容器可以用」。這個例子正好引出模式的第三個價值：可重用元件的建構。

易於重用的共享元件#

• 如果程式用到的所有程式碼都得自己寫，我們永遠做不完——今日寫的每個系統，都站在成千上萬年人類累積的心血之上：作業系統、印表機驅動、分散式資料庫、容器執行時（container runtime）、容器編排器……全都由可重用的共享函式庫與元件構成。
• 模式是定義與開發這類可重用元件的基礎：演算法的規範化帶來排序等經典演算法的可重用實作；介面模式的確立催生了實作這些模式的通用物件導向函式庫；同理，辨識出分散式系統的核心模式，就能建構共享的通用元件。
• 把這些模式實作成具備 HTTP 介面的容器映像檔，就能跨許多不同程式語言重用。
• 建構可重用元件也會提升元件本身的品質：共享的程式碼庫有足夠的使用量來暴露臭蟲與弱點，也有足夠的關注度確保它們被修復。

本章小結#

現代電腦程式所要求的可靠性、敏捷性與規模，必須靠分散式系統來實現；但分散式系統設計至今仍偏向「巫師的黑魔法」而非「常人可用的科學」。共同模式與實踐的確立，曾經規範並改進了演算法開發與物件導向程式設計——本書的目標，就是為分散式系統做同樣的事。