分層架構模式是一種n層模式，其中組件按照水平層次進行組織。這是設計大多數軟件的傳統方法，旨在實現自我獨立。這意味著所有組件之間相互連接，但彼此之間不相互依賴。

這種架構模式有四個層，每個層中的模塊性和組件之間都有連接。從上到下，它們分別是：

展示層：包含與展示相關的所有類別。

業務層：它包含業務邏輯。

持久層：用于處理對象關系映射等功能

數據庫層：存儲所有數據。

在這種情況下，各層是封閉的，也就是說請求必須從頂部到底部經過所有層。這樣設計有兩個原因，一個是將所有"相似"的組件放在一起，另一個原因是提供層次的隔離。

進一步說明，將“相似”的組件放在一起意味著與某個層相關的所有內容都保留在該單一層中。這樣可以清晰地區分各種組件，并且有助于將相似的代碼集中在一個位置。通過隔離各層，它們相互之間變得獨立。因此，例如，如果我們想將數據庫從Oracle服務器更改為SQL服務器，這將對數據庫層產生重大影響，但不會影響其他層。同樣，假設您有一個自定義的業務層，并且想要將其更改為業務規則引擎，如果我們有一個良好定義的分層架構，這種更改不會影響其他層。

分層架構模式可以在所提及的層級之外進行修改，增加其他層級。這被稱為混合分層架構。例如，在業務層和持久化層之間可以添加一個服務層。然而，這并不是理想的設計，因為現在業務層必須經過服務層才能到達持久化層。這個請求通過服務層并沒有任何價值。我們稱之為架構陷阱反模式。請求經過各層時，在每個層中幾乎沒有或沒有執行任何邏輯。

唯一解決這個問題的方法是將可選的層級設置為開放層。這意味著如果可選的層級對發送的請求有任何增值作用，請求就會經過該層級。如果沒有增值作用，請求將直接繞過該層級，進入相關的下一層級。在上圖中可以看到這種情況，請求繞過了服務層，從業務層直接進入持久化層。

然而需要注意的是，通過設置開放層，我們削弱了層級之間獨立的好處。如果我們想替換持久化層，就必須考慮到開放的服務層和業務層。這兩個層級現在都與持久化層耦合在一起。因此，雖然向系統中添加開放層非常容易，但我們不允許這種情況發生。我們必須在不損害架構的情況下解決問題。

結論

分層架構是最簡單的軟件架構模式。如果要設計一個基本的應用程序，用戶數量很少（<100-200），并且在投入使用后不會有太多的需求變化，那么這是最好的軟件架構模式。與其他模式相比，這種架構模式的實現成本非常低。

以下是分層架構模式的優劣分析。

優點

這種架構模式易于測試，因為組件屬于特定的層級。因此，它們可以單獨測試。

由于大多數應用程序自然而然地按層級工作，所以這種架構模式簡單易實現。

缺點

盡管可以對特定層進行更改，但這并不容易，因為應用程序是一個單一的單元。而且，層之間的耦合關系往往會增加難度。這也使得擴展變得困難。

它必須作為一個單一的單元部署，因此對特定層的更改意味著整個系統必須重新部署。

它的規模越大，請求經過多個層級所需的資源就越多，從而導致性能問題。