Day07 編組 (composition)

Elements of Clojure 一書，最後一個章節是談編組 (composition)。光是這個詞彙要怎麼翻譯，本身就是一個問題。composition 在不同的語境也有：『構圖』、『作曲』等不同的翻譯。在這個章節裡，作者談了如何設計單一的程序 (single process) ，也談了如何設計分散式系統 (distributed system) 。『編組』這個動作在軟體的語境，可以用來描述設計程序、也可以用來描述設計系統。

什麼是『編組』 (composition)?
資料獨立性 (data isolation)
執行獨立性 (execution isolation)
設計程序 (process)
設計系統 (system)

什麼是『編組』(composition)?

『編組』是將一個個獨立的、小型的抽象層 (abstraction) 結合起來，並且製造出一個新的、大的抽象層。編組成的抽象層也可以視為是一種『應用抽象層』(applied composition)

資料獨立性 (data isolation)

程序與程序之間的資料基本上是獨立的，資料獨立性是一種很好的特質，可以減少依賴。

從系統降低一個層級來看，函數是用來建構程序的基本單位。Clojure 語言預設是使用『不變資料結構』 (immutable data structure) ，所以也確保了函數之間的資料獨立。然而，如果函數之間使用『參考』(reference) 來傳遞引數 (parameter)，那就無法確保函數之間的資料獨立性。

執行獨立性 (execution isolation)

程序與程序之間的執行有某種程度的獨立性。然而，一個程序有時候會要等待另一個程序，一旦有等待，就有可能導致整個系統的停滯。相較於把整個系統的行為放進人的腦袋裡徹底想清楚，哪邊可能會造成系統的停滯，更簡單一點的設計方法是對程序之間的通訊，設計「等待時間的上限」 (timeout) 。 Clojure 提供了 core.async/go 和 channel ，相較於 promise 更容易實現 timeout 的語意。

設計程序

設計程序要分清楚兩種不同的關注點：一種是運作的需求 (operational concern) 、一種是功能的需求 (functional concern)。前者關注程序的運作並且定義了程序的限制 (limit)。後者則定義了該程序的用途 (purpose) 。

如果要設計健壯的程序 (robust process) ，就必須認真處理好運作的需求。比方說，程序在運作時，可能會遭遇到的種種挑戰：輸入的資料量超大、網路太慢、網路斷掉、無限期的等待…。

功能的需求主要透過『轉換已經存在於程序資料範圍的資料』(transform) 來完成。我們又可以把轉換分成三種：

增加資料 (accrete)
減少資料 (reduce)
改變資料的形狀 (reshape)

對於資料結構、演算法的研究，可以視為就是對各種不同『資料形狀』(data shape) 的優缺點的探討。我們通常會為了要使增加、減少資料變得容易而改變資料的形狀。

設計系統

設計系統的許多內容已經超出了 Elements of Clojure 一書的範圍。然而，我們還是可以探討一個很重要的系統設計模式 (pattern) ：一般而言，系統會回應來自外界的指令 (command) ，回應指令的方式是送出訊息 (message) 給程序 (process) ，透過程序彼此之間的溝通來完成一個特定的系統任務 (task) 。由於系統內部的程序 (process) 與管道 (channel) 是透過網路而連接起來，而網路的本質有其不可靠性，要完成一個特定任務時，所需要觸發的程序之間，我們應該要去妥善地處理每一段訊息溝通是否成功地完成。比方說，對傳遞失敗的情況，設計重試 (retry) 的上限次數、對於呼叫失敗加以記錄並且回報 (report)。

支持完成 (accomplish) 還有確認是否完成 (acknowledge) 系統任務 (task) 的機制，正式的名稱，稱之為『協定』 (protocol) 。『通訊的協定』 (communication protocol)，舉例來講 TCP 和 HTTP ，它們明確地規範了，系統拓撲的端點與端點之間通訊之執行機制與異常處理機制 (failure mode)。當我們設計系統時，自然必須對完成系統任務 (task) 需要的系統拓撲做相似的設計：設計『系統層級協定』 (system-level protocol) 來規範正常與異常情況的處理機制。