分層架構特定場景：程序員
分層架構是一種很常見的架構模式，它也叫N層架構。分層架構適用於一個集成不一樣功能的系統，當咱們須要把不少不一樣的代碼集起來的時候，這種模式提供了最合理的結構。能讓咱們的代碼有足夠的靈活性去應對需求改變。當系統自己不負責或者可預期的修改不多時，則不適合用分層架構，由於這樣能夠增長不少沒必要要的代碼，陷入過分設計的泥坑。不過度層架構模式是一個穩定的通用模式，這使得它成爲大部分應用程序的首選，特別是當你不肯定使用哪一個架構的時候。沒有任何一種架構模式是萬能的，因此每一個模式都必須有「適應場景」。而模式自己的內容，就是經過「模式定義」和「模塊關係」兩個層面的規定來表現出來。數據庫
分層架構解決的問題：編程
當軟件需求變動以後，基本上是對軟件代碼的修改。而軟件代碼的修改倒是程序員們最頭疼的事情。由於一些大型系統，它的代碼根本徹底看不懂，即使是瞭解了部分細節後，着手修改的時候，也會碰到牽一髮而動全身的問題。由於有些功能的修改，須要修改整個系統的不少部分，致使了無窮的BUG。另外就是在緊迫時間內，對於代碼的修改每每只能依賴有限的一個或幾個程序員，只有他們對系統最熟悉。可是，會面臨工做量巨大的問題，幾乎沒法讓更多的程序玩參與進來。假如，熟悉的程序員離職，就有可能表明了整個系統的沒法維持。即使是系統能分割給幾我的負責，在「集成」幾個部分代碼的時候，其調試和排錯工做，又經常是很持久的，由於那些歷來沒有協做過的代碼，隱藏着大量的誤解和不兼容性的問題。這一切的根源只是一個最簡單的事實，就是系統對於「代碼耦合」的結構問題。糟糕的代碼耦合讓整個系統變得難以理解，難以修改，難以分工，難以集成。而分層架構就是來解決這個耦合問題的。在這個模式中，請求流只是簡單的穿過層次，不留一點雲彩，或者說只留下一陣青煙。好比說界面層響應了一個得到數據的請求。響應層把這個請求傳遞給了業務層，業務層也只是傳遞了這個請求到持久層，持久層對數據庫作簡單的SQL查詢得到用戶的數據。這個數據按照原理返回，不會有任何的二次處理，返回到界面上。每一個分層架構或多或少均可能遇到這種場景。關鍵在於這樣的請求有多少。80-20原則能夠幫助你肯定架構是否處於反污水模式。大概有百分之二十的請求僅僅是作簡單的穿越，百分之八十的請求會作一些業務邏輯操做。然而，若是這個比例反過來，大部分的請求都是僅僅穿過層，不作邏輯操做。那麼開放一些架構層會比較好。不過因爲缺乏了層次隔離，項目會變得難以控制。數組
分層架構的解決方案：服務器
分層架構裏的組件被分紅幾個平行的層次，每一層都表明了應用的一個功能。通常狀況下，結構大多分紅四層：展現層，業務層，持久層，和數據層。有時候，業務層和持久層會合併成單獨的一個業務層，尤爲是持久層的邏輯綁定在業務層的組件當中。所以，有一些小的應用可能只有3層，一些有着更復雜的業務的大應用可能有5層或者更多的分層。例如：展現層負責處理全部的界面展現以及交互邏輯， 業務層負責處理請求對應的業務。架構裏的層次是具體工做的高度抽象，它們都是爲了實現某種特定的業務請求。例如：展現層並不須要關心怎樣獲得用戶數據，它只需在屏幕上以特定的格式展現信息。 業務層並不關心要展現在屏幕上的用戶數據格式，也不關心這些用戶數據從哪裏來。它只須要從持久層獲得數據，執行與數據有關的相應業務邏輯，而後把這些信息傳遞給展現層。分層架構的一個突出特性是組件間關注點分離。數據結構
分層架構中的每一層都着特定的角色和職能。它們中的每一層都有着特定的角色和職能。架構裏的層次是具體工做的高度抽象，它們都是爲了實現某種特定的業務請求。分層的模式的規定很是簡單有效：①每一個模塊必須屬於某個層次，提供給「第N+1層」（上層）服務；同時委派任務給「第N-1層」的模塊。②任何一個模塊。都不得逆層次調用：屬於第N層模塊的，不得調用，第N+1層或者以上層次的模塊。③任何一個模塊，都不得跨層調用：屬於第N層的模塊，不該該調用第N-2層或者更下層的模塊。以業務邏輯特徵建模，使用分層模式，每每須要咱們在大腦裏對問題領域進行層次抽象，這種抽象是可信賴的原則，就是按照業務邏輯去作。好比現實業務中有一個角色，咱們就創建一個角色的模塊，若是咱們有一個場景，就以此爲名創建一個這樣的模塊。以業務邏輯創建的模塊，自己也會讓系統更容易被理解，由於在代碼裏能找到和現實中一一對應的概念。多虧了組件分離，讓咱們更容易構造有效的角色和強力的模型。 這樣應用變的更好開發，測試，管理和維護。架構
分層架構的實例：測試
實例1：spa
好比，存在一個複雜功能的多人在線社區系統，它的服務器端是咱們須要重點討論的對象。這個產品的服務器端必須知足多樣功能：如，玩家移動到不一樣的場景中，玩家移動到不一樣的場景中，玩家能夠換上不一樣的服裝，能夠互相加好友而且能夠互相聊天，同時還有廣播頻道的聊天功能，每一個玩家還有終極的資料庫和揹包，另外還有各類運營活動。設計
在最初的開發過程當中，咱們須要針對每個須要開發的功能，創建一個模塊。這些模塊經過單獨和客戶端、數據庫的操做，完成所需功能。若是要開發新的功能，就重寫一個這樣的模塊。這種架構在一開始的時候就有效的，可是隨着產品的功能被不斷的開發出來，模塊的數量也哎增多，可是就潛藏了一個問題。
這個問題的爆發，就是隨着任務系統的功能的增多而出現的。由於任務系統本質上是不少其餘模塊功能的功能支持。如須要玩家去某個場景，得到了某個東西，而後添加了一個好友，或者換了某個時裝，發一句消息等等。這樣的任務功能實現，被迫要修改不少個模塊的代碼，由於每一個模塊都只有最基本的「自由使用」功能的代碼，編程接口都僅僅是面向客戶端的，而數據結構都是直接SQL到數據庫的。這種須要組合的功能需求，以及得到功能的結果情況，都是其接口上沒有寫的。這致使了很是複雜的，持續的代碼修改。由於任務的內容是時常會變化的。因此這個時候，咱們就須要重構整個架構。把架構從一字排開的設計，修改爲能夠多個層次互相調用的模塊。這些模塊之間的接口，有面向客戶端的也有面向其餘模塊的，這樣咱們就能直接調用那些現成的功能，組合開發出更復雜強大的功能。無論任務系統如何變化，咱們均可以不用重寫那些已經實現的功能，這讓整個系統成爲能夠應對這種需求變化的關鍵。這就是一個分層架構的實例。
實例2：
想象一個場景，用戶發出了一個請求要得到客戶的信息。在這個例子中，用戶信息由客戶數據和訂單數組組成(客戶下的訂單)。用戶界面只管接受請求以及顯示客戶信息。它無論怎麼獲得數據的，或者說獲得這些數據要用到哪些數據表。若是用戶界面接到了一個查詢客戶信息的請求，它就會轉發這個請求給用戶委託(Customer Delegate)模塊。這個模塊能找到業務層裏對應的模塊處理對應數據(約束關係)。業務層裏的customer object聚合了業務請求須要的全部信息(在這個例子裏獲取客戶信息)。這個模塊調用持久層中的 customer dao 來獲得客戶信息，調用order dao來獲得訂單信息。這些模塊會執行SQL語句，而後返回相應的數據給業務層。當 customer object收到數據之後，它就會聚合這些數據而後傳遞給 customer delegate,而後傳遞這些數據到customer screen 展現在用戶面前。
優勢：
1.結構簡單，容易理解和開發
2.不一樣技能的程序員能夠分工，負責不一樣的層，適合大多數軟件公司的組織架構
3.每一層均可以獨立測試，其餘層的接口能夠模擬解決。
缺點：
1.一旦環境變化，須要代碼調整或增長工能時，一般比較麻煩和費時
2.部署比較麻煩，即時只修改一個小地方，每每須要整個軟件從新部署，不容易作持續發佈。
3.軟件升級時，可能須要整個服務中止。
4.擴展性差，用戶請求大量增長時，必須一次擴展每一層，因爲每一層內部是耦合的，擴展會很困難。