.NET邏輯分層架構總結

　　一.基礎知識準備：

　　1.層的原則：

　　（1）每一層以接口方式供上層調用。
　　（2）上層只能調用下層。
　　（3）依賴分爲鬆散交互和嚴格交互兩種。

　　2.業務邏輯分類：

　　（1）應用邏輯。
　　（2）領域邏輯。

　　3.採用的層：

　　（1）表示層（用戶接口層）：領域無關。
　　（2）服務層（應用層）：應用邏輯。
　　（3）業務邏輯層（領域層）：領域邏輯。
　　（4）共享層：提供通用代碼。
　　（5）實現層：提供接口實現。

　　4.約定：

　　（1）領域層默認採用領域模型
　　（2）數據訪問層默認須要引用領域模型

　　二.分層架構

　　分層架構的三個基本層次爲：表示層、業務邏輯層和數據訪問層。若是按照業務邏輯的分類將業務邏輯層分解爲服務層和領域層，則三層擴展爲四個層次：表示層、服務層、領域層和數據訪問層。數據訪問層通常必須瞭解領域模型，這將在層之間產生雙向依賴，一般咱們有以下兩種解決方案：

　　1.將領域模型放置在共享層：

 

　　評價：PetShop採用此種模型，但缺點衆多：業務邏輯層名存實亡，領域模型實爲數據模型，保持了層間依賴，引入了更多依賴，明顯的數據驅動思想，沒有以領域爲核心。

　　2.將數據訪問接口定義在業務邏輯層：

 

　　評價：NopCommerce採用此種模型，即便採用分離出了服務層和採用了資源庫命名方式，但NopCommerce不是DDD分層架構，只是採用了領域模型和接口分離原則的普通三層架構。缺點：除了數據房產，沒有將其餘具體的技術依賴從業務邏輯層中分離。

　　三.DDD分層：

　　DDD分層明確的將業務邏輯層分紅了應用層（服務層）和領域層兩部分。同時將數據訪問和其餘接口的具體技術實現部分統一到了基礎設施層。

　　1.原始的DDD分層：

 

　　評價：優勢是將具體技術實現從領域分離，基礎設施層複用價值增長。缺點是沒有使用共享和實現的概念細分基礎設施層，致使在基礎設施層中實現倉儲會產生反向依賴，雖然在單項目解決方案中沒有影響（僅命名空間層次的形式上的依賴），但在.NET多項目解決方案中，只能經過接口分離方式將倉儲實現獨立成相似數據訪問層的方式。

　　2.改善的DDD分層：

 

　　評價：基礎設施層同時具備共享層和實現層的特徵。優勢是終於作到了形式上領域爲核心且同時解決了在基礎設施層中實現倉儲不能引用領域模型的尷尬，缺點是一樣沒有區分共享和實現的概念。

　　3.最新的DDD分層：

 

　　評價：優勢是這是真正的以領域爲核心，不再用爲基礎設施層沒法引用領域層而再服務層中再次適配了。使用依賴倒置原則完全各層對具體技術的依賴倒置。缺點，依賴倒置應用過了頭，一樣是在單項目解決方案中沒有問題，但在.NET多項目解決方案中會致使命名空間形式上的雙向依賴。基礎設施層做爲實現層基本上沒有了複用的價值。更好的方式是調換圖中用戶接口層和基礎設施層的位置。

 

　　能夠根據須要考慮在上圖添加適當的共享層。

　　四.架構的趨勢：

　　（1）以業務邏輯爲核心，更加劇視業務邏輯。
　　（2）將業務邏輯層的具體依賴劃分到一個層次統一管理。
　　（3）更加劇視下降解決方案內的依賴性而不是解決方案間的代碼複用。
　　（4）共享層和實現層的分離將會愈來愈多的體現。例如洋蔥型架構。

　　參考

　　1.Patterns of Enterprise Application Architecture 【企業應用架構模式】　　2.Domain-Driven Design 【領域驅動設計：軟件核心複雜性應對之道】　　3.Applying Domain-Driven Design and Patterns【領域驅動設計與模式實戰】　　4.Implementing Domain-Driven Design 【實現領域驅動設計】　　5.Microsoft Application Architecture Guide 【微軟應用架構指南（第2版）】　　6.Professional Enterprise .NET 【精通.NET企業項目開發：最新的模式、工具與方法】　　7.Professional ASP.NET Design Patterns 【ASP.NET設計模式】