顯示 變化 設計 分離 領域 消息 對數 原則 數據格式

分層架構特定場景：分層架構是一種很常見的架構模式，它也叫N層架構。分層架構適用於一個集成不同功能的系統，當我們需要把很多不同的代碼集起來的時候，這種模式提供了最合理的結構。能讓我們的代碼有足夠的靈活性去應對需求改變。當系統本身不負責或者可預期的修改很少時，則不適合用分層架構，因為這樣可以增加很多不必要的代碼，陷入過度設計的泥坑。不過分層架構模式是一個穩定的通用模式，這使得它成為大部分應用程序的首選，特別是當你不確定使用哪個架構的時候。沒有任何一種架構模式是萬能的，所以每個模式都必須有“適應場景”。而模式本身的內容，就是通過“模式定義”和“模塊關系”兩個層面的規定來表現出來。

分層架構解決的問題：

當軟件需求變更之後，基本上是對軟件代碼的修改。而軟件代碼的修改卻是程序員們最頭疼的事情。因為一些大型系統，它的代碼根本完全看不懂，即便是了解了部分細節後，著手修改的時候，也會碰到牽一發而動全身的問題。因為有些功能的修改，需要修改整個系統的很多部分，導致了無窮的BUG。另外就是在緊迫時間內，對於代碼的修改往往只能依賴有限的一個或幾個程序員，只有他們對系統最熟悉。但是，會面臨工作量巨大的問題，幾乎無法讓更多的程序玩參與進來。假如，熟悉的程序員離職，就有可能代表了整個系統的無法維持。即便是系統能分割給幾個人負責，在“集成”幾個部分代碼的時候，其調試和排錯工作，又常常是很持久的，因為那些從來沒有協作過的代碼，隱藏著大量的誤解和不兼容性的問題。這一切的根源只是一個最簡單的事實，就是系統對於“代碼耦合”的結構問題。糟糕的代碼耦合讓整個系統變得難以理解，難以修改，難以分工，難以集成。而分層架構就是來解決這個耦合問題的。在這個模式中，請求流只是簡單的穿過層次，不留一點雲彩，或者說只留下一陣青煙。比如說界面層響應了一個獲得數據的請求。響應層把這個請求傳遞給了業務層，業務層也只是傳遞了這個請求到持久層，持久層對數據庫做簡單的SQL查詢獲得用戶的數據。這個數據按照原理返回，不會有任何的二次處理，返回到界面上。每個分層架構或多或少都可能遇到這種場景。關鍵在於這樣的請求有多少。80-20原則可以幫助你確定架構是否處於反汙水模式。大概有百分之二十的請求僅僅是做簡單的穿越，百分之八十的請求會做一些業務邏輯操作。然而，如果這個比例反過來，大部分的請求都是僅僅穿過層，不做邏輯操作。那麽開放一些架構層會比較好。不過由於缺少了層次隔離，項目會變得難以控制。

分層架構的解決方案：分層架構裏的組件被分成幾個平行的層次，每一層都代表了應用的一個功能。一般情況下，結構大多分成四層：展示層，業務層，持久層，和數據層。有時候，業務層和持久層會合並成單獨的一個業務層，尤其是持久層的邏輯綁定在業務層的組件當中。因此，有一些小的應用可能只有3層，一些有著更復雜的業務的大應用可能有5層或者更多的分層。例如：展示層負責處理所有的界面展示以及交互邏輯， 業務層負責處理請求對應的業務。架構裏的層次是具體工作的高度抽象，它們都是為了實現某種特定的業務請求。例如：展示層並不需要關心怎樣得到用戶數據，它只需在屏幕上以特定的格式展示信息。 業務層並不關心要展示在屏幕上的用戶數據格式，也不關心這些用戶數據從哪裏來。它只需要從持久層得到數據，執行與數據有關的相應業務邏輯，然後把這些信息傳遞給展示層。分層架構的一個突出特性是組件間關註點分離。

分層架構中的每一層都著特定的角色和職能。它們中的每一層都有著特定的角色和職能。架構裏的層次是具體工作的高度抽象，它們都是為了實現某種特定的業務請求。分層的模式的規定非常簡單有效：①每個模塊必須屬於某個層次，提供給“第N+1層”（上層）服務；同時委派任務給“第N-1層”的模塊。②任何一個模塊。都不得逆層次調用：屬於第N層模塊的，不得調用，第N+1層或者以上層次的模塊。③任何一個模塊，都不得跨層調用：屬於第N層的模塊，不應該調用第N-2層或者更下層的模塊。以業務邏輯特征建模，使用分層模式，往往需要我們在大腦裏對問題領域進行層次抽象，這種抽象是可信賴的原則，就是按照業務邏輯去做。比如現實業務中有一個角色，我們就建立一個角色的模塊，如果我們有一個場景，就以此為名建立一個這樣的模塊。以業務邏輯建立的模塊，本身也會讓系統更容易被理解，因為在代碼裏能找到和現實中一一對應的概念。多虧了組件分離，讓我們更容易構造有效的角色和強力的模型。 這樣應用變的更好開發，測試，管理和維護。

分層架構的實例：

實例1：比如，存在一個復雜功能的多人在線社區系統，它的服務器端是我們需要重點討論的對象。這個產品的服務器端必須滿足多樣功能：如，玩家移動到不同的場景中，玩家移動到不同的場景中，玩家可以換上不同的服裝，可以互相加好友並且可以互相聊天，同時還有廣播頻道的聊天功能，每個玩家還有終極的資料庫和背包，另外還有各種運營活動。

在最初的開發過程中，我們需要針對每一個需要開發的功能，建立一個模塊。這些模塊通過單獨和客戶端、數據庫的操作，完成所需功能。如果要開發新的功能，就重寫一個這樣的模塊。這種架構在一開始的時候就有效的，但是隨著產品的功能被不斷的開發出來，模塊的數量也哎增多，但是就潛藏了一個問題。

這個問題的爆發，就是隨著任務系統的功能的增多而出現的。因為任務系統本質上是很多其他模塊功能的功能支持。如需要玩家去某個場景，獲得了某個東西，然後添加了一個好友，或者換了某個時裝，發一句消息等等。這樣的任務功能實現，被迫要修改很多個模塊的代碼，因為每個模塊都只有最基本的“自由使用”功能的代碼，編程接口都僅僅是面向客戶端的，而數據結構都是直接SQL到數據庫的。這種需要組合的功能需求，以及獲得功能的結果狀況，都是其接口上沒有寫的。這導致了非常復雜的，持續的代碼修改。因為任務的內容是時常會變化的。所以這個時候，我們就需要重構整個架構。把架構從一字排開的設計，修改成可以多個層次互相調用的模塊。這些模塊之間的接口，有面向客戶端的也有面向其他模塊的，這樣我們就能直接調用那些現成的功能，組合開發出更復雜強大的功能。不管任務系統如何變化，我們都可以不用重寫那些已經實現的功能，這讓整個系統成為可以應對這種需求變化的關鍵。這就是一個分層架構的實例。

實例2：想象一個場景，用戶發出了一個請求要獲得客戶的信息。在這個例子中，用戶信息由客戶數據和訂單數組組成(客戶下的訂單)。用戶界面只管接受請求以及顯示客戶信息。它不管怎麽得到數據的，或者說得到這些數據要用到哪些數據表。如果用戶界面接到了一個查詢客戶信息的請求，它就會轉發這個請求給用戶委托(Customer Delegate)模塊。這個模塊能找到業務層裏對應的模塊處理對應數據(約束關系)。業務層裏的customer object聚合了業務請求需要的所有信息(在這個例子裏獲取客戶信息)。這個模塊調用持久層中的 customer dao 來得到客戶信息，調用order dao來得到訂單信息。這些模塊會執行SQL語句，然後返回相應的數據給業務層。當 customer object收到數據以後，它就會聚合這些數據然後傳遞給 customer delegate,然後傳遞這些數據到customer screen 展示在用戶面前。

優點：

1.結構簡單，容易理解和開發

2.不同技能的程序員可以分工，負責不同的層，適合大多數軟件公司的組織架構

3.每一層都可以獨立測試，其他層的接口可以模擬解決。

缺點：

1.一旦環境變化，需要代碼調整或增加工能時，通常比較麻煩和費時

2.部署比較麻煩，即時只修改一個小地方，往往需要整個軟件重新部署，不容易做持續發布。

3.軟件升級時，可能需要整個服務停止。

4.擴展性差，用戶請求大量增加時，必須一次擴展每一層，由於每一層內部是耦合的，擴展會很困難。

軟件架構之分層架構理解