參考：http://www.ruanyifeng.com/blog/2016/09/software-architecture.html
https://blog.csdn.net/bboyfeiyu/article/details/45136299
https://www.cnblogs.com/zdxster/p/5305155.html
1. 什么是分層架構
分層架構是一種很常見的架構模式，它也叫N層架構。這種架構是大多數Jave EE應用的實際標准，因此很多的架構師，設計師，還有程序員都知道它。許多傳統IT公司的組織架構和分層模式十分的相似。所以它很自然的成為大多數應用的架構模式。
2. 模式分析
分層架構模式里的組件被分成幾個平行的層次，每一層都代表了應用的一個功能(展示邏輯或者業務邏輯)。盡管分層架構沒有規定自身要分成幾層幾種，大多數的結構都分成四個層次:展示層，業務層，持久層，和數據庫層。有時候，業務層和持久層會合並成單獨的一個業務層，尤其是持久層的邏輯綁定在業務層的組件當中。因此，有一些小的應用可能只有3層，一些有着更復雜的業務的大應用可能有5層或者更多的分層。
分層架構中的每一層都有着特定的角色和職能。
舉個例子，展示層負責處理所有的界面展示以及交互邏輯，業務層負責處理請求對應的業務。架構里的層次是具體工作的高度抽象，它們都是為了實現某種特定的業務請求。比如說展示層並不需要關心怎樣得到用戶數據，它只需在屏幕上以特定的格式展示信息。業務層並不關心要展示在屏幕上的用戶數據格式，也不關心這些用戶數據從哪里來。它只需要從持久層得到數據，執行與數據有關的相應業務邏輯，然后把這些信息傳遞給展示層。
分層架構的一個突出特性是組件間關注點分離 (separation of concerns)。一個層中的組件只會處理本層的邏輯。比如說，展示層的組件只會處理展示邏輯，業務層中的組件只會去處理業務邏輯。多虧了組件分離，讓我們更容易構造有效的角色和強力的模型。這樣應用變的更好開發，測試，管理和維護。
3. 關鍵概念——層隔離
這是分層架構中非常重要的特點。這意味request必須一層一層的傳遞。舉個例子，從展示層傳遞來的請求首先會傳遞到業務層，然后傳遞到持久層，最后才傳遞到數據層。
那么為什么不允許展示層直接訪問數據層呢。如果只是獲得以及讀取數據，展示層直接訪問數據層，比穿過一層一層來得到數據來的快多了。這涉及到一個概念:層隔離。
層隔離就是說架構中的某一層的改變不會影響到其他層:這些變化的影響范圍限於當前層次。如果展示層能夠直接訪問持久層了，假如持久層中的SQL變化了，這對業務層和展示層都有一定的影響。這只會讓應用變得緊耦合，組件之間互相依賴。這種架構會非常的難以維護。
從另外一個方面來說，分層隔離使得層與層之間都是相互獨立的，架構中的每一層的互相了解都很少。為了說明這個概念的厲害之處，想象一個超級重構，把展示層從JSP換成JSF。假設展示層和業務層的之間的聯系保持一致，業務層不會受到重構的影響，它和展示層所使用的界面架構完全獨立。
然而封閉的架構層次也有不便之處，有時候也應該開放某一層。如果想往包含了一些由業務層的組件調用的普通服務組件的架構中添加一個分享服務層。在這個例子里，新建一個服務層通常是一個好主意，因為從架構上來說，它限制了分享服務訪問業務層(也不允許訪問展示層)。如果沒有隔離層，就沒有任何架構來限制展示層訪問普通服務，難以進行權限管理。
開放和封閉層的概念確定了架構層和請求流之間的關系，並且給設計師和開發人員提供了必要的信息理解架構里各種層之間的訪問限制。如果隨意的開放或者封閉架構里的層，整個項目可能都是緊耦合，一團糟的。以后也難以測試，維護和部署。
4. 分層架構使用的特定環境
一個需要分解的比較大的系統。這種模式對大部分JAVAEE應用程序來說是標准模式，因此被大部分架構師、軟件設計師、開發者廣泛知曉。由於分層架構模式和公司里傳統的IT溝通以及組織結構非常類似，使得它成為大多數商務應用開發最自然的選擇。分層的開發方式實現了人類對復雜事物的普遍處理方式——分而治之。通過把復雜的系統分解成為相對簡單的獨立系統，低耦合的分解既可以實現開發人員的並行工作，又可以實現開發人員的任務分工。而且通過分層，對組件拼裝和流水化作業提供了理論和事實的基礎。
5. 分層模式用來解決什么問題？
分層模式的關鍵點在於確定依賴：即通過分層，可以限制子系統間的依賴關系，使系統以更松散的方式耦合，從而更易於維護。
典型的分層方式是應用程序專用功能位於上層，跨越應用程序領域的功能位於中層，而配置環境專用功能位於低層。層的數量與組成取決於問題領域和解決方案的復雜程度。通常而言只有一個應用程序專用層。應當把子系統組織成分層結構，架構的上層是應用程序專用子系統，架構的低層是硬件和操作專用子系統，中間件層是通用服務。
對系統進行分層有如下基本原則：
●可見度。各子系統只能與同一層及其下一層的子系統存在依賴關系。
●易變性。最上層放置隨用戶需求的改變而改變的元素。最底層放置隨實施平台（硬件、語言、操作系統、數據庫等）的改變而改變的元素。中間的夾層放置廣泛適用於各種系統和實施環境的元素。如果在這些大類中進一步划分有助於對模型進行組織，則添加更多的層。
●通用性。一般將抽象的模型元素放置在模型的低層。如果它們不針對於具體的實施，則傾向於將其放置在中間層。
●層數。對於小型系統，三層就足夠了。對於復雜系統，通常需要5-7層。無論復雜程度如何，如果超過10層，就需要慎重考慮了。層數越多，越需慎重。
6. 分層模式的解決方案
分層架構是常用的架構模式，對於一個大系統可以划分為幾個子系統，各子系統位於不同的抽象層次。各層間上層依賴下層服務，下層不能依賴上層。消息可以從上向下，也可以從下向上。自頂向下調用下層接口，稱為請求。自低向上的通信，稱為通知，一般使用回調方法，從而實現單路徑耦合。
【分層的步驟】
1、定義抽象准則
2、根據准則定義抽象層數
3、給每個層命名並指定任務
4、指定服務
5、細化分層，重復上述步驟，直到一個穩定的分層結構
6、為每層指定接口
7、構建獨立層
8、指定層間通信，分離臨接層
9、設計錯誤處理策略
【分層的優點】
分層架構模式是個可靠的通用模式，對於大部分應用它是個很好的開始，尤其當不知道哪種結構適合使用時。
1、降低復雜度，上層不需要關注下層細節。
2、提高靈活性，可以靈活替換某層的實現。
3、減小耦合度，將層次間的依賴減到最低。
4、有利於重用，同一層次可以有多種用途。
5、有利於標准化。
它有如下幾點優勢：重用性好、標准化支持、局部依賴、可替換性
【分層的缺點】
分層主要有以下的缺點：影響多層次的修改；降低了效率；多層傳遞，重復的工作；層的粒度難以把握。
1、不能封裝所有工作，可能會帶來及聯修改。
2、過多層次影響性能。
分層的難點主要有： 1、如何划分層次。
2、定義層次職責。
分層的多層傳遞中有現象被稱為污水池反模式（architecture sinkhole anti-pattern）。該反模式描述的是這樣的場景，請求流穿過架構的很多層，每一層只有少量的甚至沒有業務邏輯。例如，假設展示層響應用戶的請求獲取客戶信息，展示層將請求傳遞給業務層，業務層什么也不做，僅僅將請求直接傳遞給持久層，持久層執行SQL語句獲取數據。數據在回傳過程中沒有經過任何的處理。
每個分層架構都可能會有一些場景落入污水池反模式。然而關鍵是分析這樣的請求占了多少比例。通常80-20定律可用來分析是否落入了污水池反模式。當反模式的比例比較大時，你或許考慮將某些層開放，這時要注意缺乏層隔離，會使得以后修改時比較困難。
分層架構會使應用變得龐大，即使把表示層和業務層分成了單獨的部署單元。這對某些應用不需要考慮，但是也會帶來一些部署的隱患，如健壯性、可靠性、性能和可伸縮性。
【分層演化過程】
單層架構-->兩層架構-->三層架構-->N層架構
單層架構：早期批處理系統
兩層架構：C/S 客戶/服務器模式
特點：沒有復雜的領域邏輯
優點：有非常好的工具支持，VB、Delphi、PowerBuilder
缺點：代碼冗余，難於維護。
模式：1、領域邏輯寫在客戶端
2、領域邏輯寫在數據庫（存儲過程）
面向對象技術、WEB興起、Java出現共同推進了三層架構。
Layer與Tier的區別：1、Tier強調物理上的分離，Two Tier System。2、Layer強調邏輯上的分層。
三層架構：表現層-領域層-數據源層（持久層）
1、表現層：提供服務，顯示信息。
2、領域層：系統核心邏輯。
3、數據源層：與數據庫、消息系統以及其他軟件包通信
7.分層架構應用實例
為了演示分層架構是如何工作的，想象一個場景，如圖，用戶發出了一個請求要獲得客戶的信息。黑色的箭頭是從數據庫中獲得用戶數據的請求流，紅色箭頭顯示用戶數據的返回流的方向。在這個例子中，用戶信息由客戶數據和訂單數組組成（客戶下的訂單）。
其中，Presentation 層代表了代碼中的jsp界面層；Business 層代表代碼中處理請求並返回結果的servlet層；Persistence持久層代表代碼中的dao層；Database數據層代表了代碼中的sql語句。
用戶界面只管接受請求以及顯示客戶信息。它不管怎么得到數據的，或者說得到這些數據要用到哪些數據表。如果用戶界面接到了一個查詢客戶信息的請求，它就會轉發這個請求給用戶委托(Customer Delegate）模塊。這個模塊能找到業務層里對應的模塊處理對應數據（約束關系）。業務層里的customer object聚合了業務請求需要的所有信息（在這個例子里獲取客戶信息）。這個模塊調用持久層中的custom dao來得到客戶信息，調用order dao來得到訂單信息。這些模塊會執行SQL語句，然后返回相應的數據給業務層當customer object收到數據以后，它就會聚合這些數據然后傳遞給customer delegate，然后傳遞這些數據到customer screen展示在用戶面前。
8. 分層架構與MVC之間的區別
我相信很多人都會對這兩個概念模糊，下面我們來分析一下這兩者之間的區別與聯系。
三層架構是一個分層式的軟件體系架構設計，它可適用於任何一個項目。
MVC是一個設計模式，它是根據項目的具體需求來決定是否適用於該項目。
那么架構跟設計模式有什么區別呢？
我們從接手一個項目開始，首先，我們需要進行架構設計，一般我們采用的就是分層式的架構設計，即我們的三層架構。然后，在確定了架構以后，我們再根據項目的具體需求去考慮是否需要應用一些設計模式，比如是否應用我們的MVC模式，抽象工廠模式等等。最后，確定了模式以后，就是我們的一些具體的實現了。
其次，它倆划分的層次不同。
三層架構將整個項目划分為：表現層（UI）、業務邏輯層（BLL）、數據訪問層（DAL）。
MVC 即Model（模型），View（視圖），Controller（控制）。
而我們通常所見到的MVC一般也都是在應用三層架構的基礎上，即將Model層再進行分層。而如果Model不再進行划分的話，那么使用MVC的意義也就不大了。
然后，它倆的目的着重點不同。
三層架構的目的着重點是“高內聚，低耦合”，即解耦。
MVC的目的則是實現Web系統的職能分工，即職責划分。
其實職責划分也是解耦，但是三層側重的是整體的一個解耦，而MVC側重的是web系統的解耦，即側重jsp和Servlet的一個解耦。
MVC和三層架構MVC與三層架構類似么？
三層架構是典型的架構模式（Architecture Pattern），三層架構的分層模式是典型的上下關系，上層依賴於下層。但MVC作為表現模式是不存在上下關系的，而是相互協作關系。即使將MVC當作架構模式，也不是分層模式。MVC和三層架構基本沒有可比性，是應用於不同領域的技術。
分層架構是常用的架構模式，對於一個大系統可以划分為幾個子系統，各子系統位於不同的抽象層次。各層間上層依賴下層服務，下層不能依賴上層。消息可以從上向下，也可以從下向上。自頂向下調用下層接口，稱為請求。自低向上的通信，稱為通知，一般使用回調方法，從而實現單路徑耦合。