引自：《Software Architecture Patterns》

附腦圖

分層架構

分層架構（layered architecture）是最常見的軟體架構，也是事實上的標準架構。

• 解耦方式：每一層都有清晰的角色和分工，而不需要知道其他層的細節。
• 通訊方式：層與層之間通過介面通訊。

各層級的定義：

1. 表現層（presentation）：使用者介面，負責視覺和使用者互動
2. 業務層（business）：實現業務邏輯
3. 持久層（persistence）：提供資料，SQL 語句就放在這一層
4. 資料庫（database） ：儲存資料

So why not allow the presentation layer direct access to either the persistence layer or database layer? After all, direct database access from the presentation layer is much faster than going through a bunch of unnecessary layers just to retrieve or save database information. The answer to this question lies in a key concept known as layers of isolation

The layers of isolation concept means that changes made in one layer of the architecture generally don’t impact or affect components in other layers: the change is isolated to the components within that layer, and possibly another associated layer (such as a persistence layer containing SQL).

The layers of isolation concept also means that each layer is independent of the other layers, thereby having little or no knowledge of the inner workings of other layers in the architecture.

層級隔離的設計理念，使得層與層之間實現了高內聚、低耦合。

Creating a services layer is usually a good idea in this case because architecturally it restricts access to the shared services to the business layer (and not the presentation layer). Without a separate layer, there is nothing architecturally that restricts the presentation layer from accessing these common services, making it difficult to govern this access restriction.

層級架構也使得增加新的業務層更加容易——因為層級（模組）間的耦合度很低，新的層級只需要處理層與層之間的介面就OK了。

示例

調整業務結構，我們增加一個新的層級——服務層。

The services layer in this case is marked as open,  meaning requests are allowed to bypass this open layer and go directly to the layer below it.

In the following example, since the services layer is open, the business layer is now allowed to bypass it and go directly to the persistence layer, which makes perfect sense.

由於新的層級是開放的而非閉合的，它允許上游層越過自身，實現直接對下游層資料的訪問。

小結

分層架構可以直觀的實現不同層級邏輯程式碼的解耦合，除此之外：

• 結構簡單，容易理解和開發
• 不同技能的程式設計師可以分工，負責不同的層，天然適合大多數軟體公司的組織架構
• 每一層都可以獨立測試，其他層的介面通過模擬解決

缺點：

• 一旦環境變化，需要程式碼調整或增加功能時，通常比較繁雜和費時
• 部署很麻煩：即使只修改一個小地方，往往需要整個軟體重新部署，不容易做持續釋出
• 軟體升級時，可能需要整個服務暫停
• 擴充套件性差：使用者請求大量增加時，必須依次擴充套件每一層，由於每一層內部是耦合的，擴充套件會很困難

模式分析：

• 總體靈活性： 低
• 釋出易用性： 低
• 可測試性： 高
• 效能： 低
• 規模擴充套件性： 低
• 開發容易度： 高

In the following example, since theservices layer is open, the business layer is now allowed to bypass itand go directly to the persistence layer, which makes perfect sense.