這是我參與8月更文挑戰的第11天，活動詳情查看：8月更文挑戰程序員

架構設計模式

沒有進行架構設計的應用程序一般是緊耦合的，難以維護和擴展。若是不理解應用的各個組件的內部工做方式的話很難看清它的架構特徵。數據庫

關於部署和維護的問題都很難回答：設計模式

軟件架構模式能夠幫助你定義程序的基本特徵和行爲。例如一些架構模式很天然讓程序成爲大規模(scalable)的程序。有些模式讓程序變得靈巧敏捷(agile)。知道這些架構的特徵，優勢和缺點，你就能夠根據你特定的業務需求和目標從容地選擇一種架構模式。性能

做爲一位架構師，你總會爲本身的架構選擇作解釋，尤爲你選擇一個特別的架構模式的時候。學習

軟件架構法則

軟件架構第必定律：軟件架構中的全部東西都是一種權衡(Everything in software architecture is a trade-off)

咱們對軟件架構的定義超越告終構的範疇，包含了原則、特性等，架構的範圍比單純的結構更廣，體如今咱們的軟件架構第二定律中：爲何比怎麼作更重要（Why is more important than how）

分層架構 (Layered Architecture)

它是最通用的架構，也被叫作 N 層架構模式(n-tier architecture pattern)。這也是 Java EE 應用常常採用的標準模式。基本上是個程序員都比較熟悉它。

這種架構模式很是適合傳統的 IT 通訊和組織結構，很天然地成爲大部分應用的第一架構選擇。

在分層架構中的組件被劃分紅幾個層，每一個層表明應用的一個功能，都有本身特定的角色和職能。

分層架構自己沒有規定要分紅多少層，大部分的應用會分紅表現層、業務層、持久層和數據層。

小的應用有時候會將業務層和持久層合在一塊兒，更大規模的應用可能會劃分更多的層，好比調用外部服務的層。

分層架構的一個特性就是關注分離(separation of concerns)。該層中的組件只負責本層的邏輯，組件的劃分很容易讓它們實現本身的角色和職責，也比較容易地開發，測試管理和維護。

注意每一層都是封閉的，這意味着 Request 必須通過每一層才能到達最底下一層。

Q：爲何不容許展現層直接訪問數據庫層呢，這樣不是更快嗎？

這就是分層架構的另外一個特徵：層隔離(layers of isolation)。

層隔離的概念意味着你對任何一層的改變都不會影響其它層，這很好理解，同時也意味着一個層的組件並不會瞭解其它層的實現，或者知道不多。

好比業務層不需知道你持久層是如何具體實現的。

分層架構也很容易增長新的層。

好比你想將一些通用的服務重構成一個服務層，好比通用圖片處理，遠程帳戶審計等，能夠在業務層下增長一個服務層。它不會對展現層形成影響，也不會改變持久層的代碼。

上面的這個例子帶來一個問題，由於每一層丟失封閉的，業務層不得不經過服務層訪問持久層，這沒有天理啊。因此有時候你會建立一個開放的層。這意味着上一層能夠繞過這一層直接訪問下一層。

分層架構是一個可靠的通用的架構，對不少應用來講，若是你不肯定哪一種架構適合你的應用，能夠用它做爲一個初始架構。一、要注意的是污水池反模式(architecture sinkhole anti-pattern)

所謂污水池反模式，就是請求流簡單的穿過幾個層，每層裏面基本沒有作任何業務邏輯，或者作了不多的業務邏輯。好比一些 JavaEE 例子，業務邏輯層只是簡單的調用了持久層的接口，自己沒有什麼業務邏輯。

每一層或多或少都有可能遇到這樣的場景，關鍵是分析這樣的請求的百分比是多少。二八原則能夠幫助你決定是否正在遇到污水池反模式。若是你的請求超過 20%，你應該考慮讓一些層變成開放的。

二、須要考慮的是分層架構可能會讓你的應用變得龐大

即便你的展現層和業務層能夠獨立發佈（好比展現層使用單頁技術框架 AngularJS, EmberJS）。

它的確會帶來一些潛在的問題，好比分佈模式複雜，健壯性降低，可靠性，性能和規模等。

結合上文分析，分層架構設計模式總體分析以下：

- END -

做者：架構精進之路，十年研發風雨路，大廠架構師，CSDN 博客專家，專一架構技術沉澱學習及分享，職業與認知升級，堅持分享接地氣兒的乾貨文章，期待與你一塊兒成長。
關注並私信我回復「01」，送你一份程序員成長進階大禮包，歡迎勾搭。

文章首發於同名公衆號《架構精進之路》，原文連接：軟件架構模式之分層架構

Thanks for reading!