軟體架構模式（1）：Layers

Nov. 21 16:35~17:43

 

上禮拜六上完「Design Patterns這樣學就會了：進階實作班」有學員問Teddy除了GoF的23個patterns有沒有其他pattern可以介紹？想來想去先從比較常見的軟體架構模式介紹起，這一系列文章挑選《POSA》（Pattern-Oriented Software Architecture）書中比較常聽到的模式來介紹。

Layers

首先介紹Layers（階層、分層）架構，它的主要用途是將系統分解成若干個具備相同抽像層次的群組，每個群組就稱曾一個layer。

Context：你所設計個系統其主要特性必須要解決高階與低階的議題，在其中高階的議題相依於低階的議題。

Problem：如何分解一個大系統？

Forces：

• 某個元件的異動不應該引發漣波效應影響到整個系統。
• 界面應該非常穩定，甚至被標準組織訂為規格。
• 系統的部分元件可以被其他實作方式替換而不影響系統其餘部分的運作。
• 在日後可能會使用相同的底層功能來建構其他不同的系統。
• 相似的責任應該被放在一起以助以理解與維護系統。
• 沒有標準的元件粒度大小規範。
• 複雜的元件需要更進一步的分解。
• 跨越元件邊界可能會有損效能。
• 系統由一組開發人員所建構，而且工作必須要切割成清楚的界線。需求通常在架構設計階段被審視。

Solution：將系統切割成合適數量的階層，從最低階層的抽象化開始定義，稱它為Layer 1。以此為基礎逐層往上定義，讓Layer J在Layer J-1之上，一直到最上層Layer N為止。

Resulting Context：

• 只要Layer有清楚的抽象層，它可能可以在不同的情境（context）被重複使用。
• 支援標準化與互換性。
• 相依性被控制在區域端，標準化的階層介面讓相依性控制在上下兩個階層之間。
• 階層內的行為（介面）改變可能會引發一連串的行為改變。例如，將網路底層由10Mb的乙太網路換成155MB的ATM網路，上層模組可能因為記憶體、執行效率等問題的支援導致一連串的修改。
• 階層可能導致執行效率降低。
• 非必要的工作。如果低層所做的若干處裡並沒有被高層模組所使用到則會造成非必要的浪費。例如在網路傳輸中底層為了多工（multiplexing）傳輸而增加了額外欄位來處裡，但高層應用程式並不一定需要多工服務。
• 階層的粒度（granulartty）不容易定義，定義太少階層可能降低重複使用性與替換性，定義太多階層造層不必要的複雜性。

Known Uses：Virtual Machines、Information System（一般資訊系統可分為Presentation、Application、Domain、Database這幾層）、Windows NT（迷之音：好古老的例子）。

***

在傳統的階層架構中，上層會相依於下層。如果要避免這個問題，可以參考〈Dependency-Inversion Principle〉，相依反倒原則。

***

友藏內心獨白：分層負責。