ddd 架構設計——abp

1、爲何要分層

分層架構是全部架構的鼻祖，分層的做用就是隔離，不過，咱們有時候有個誤解，就是把層和程序集對應起來，就好比簡單三層架構中，在你的解決方案中，通常會有三個程序集項目：XXUI.dll、XXBLL.dll 和 XXDAL.dll，而後把這三個程序集當作一個層，這沒什麼不能夠，但當項目複雜的時候，若是還按照這種方式的話，你的程序集中的文件夾會愈來愈多，程序集也會愈來愈大。當你的視野跳出這個程序集的概念後，你會發現，層不僅是和程序集對應，也和解決方案文件夾，或者是整個解決方案對應，一個層甚至能夠對應一個系統。

分層的目的即爲了「高內聚低耦合」的思想。

2、微軟經典的三層架構

任何一個.net都知道的微軟的三層架構，三層架構就是把業務劃分爲界面層（User Interface layer）、業務邏輯層（Business Logic Layer）、數據訪問層（Data access layer）。以下圖

各層的做用：

界面層(UI)：主要表示WEB方式，也能夠表示成WINFORM方式;若是邏輯層至關強大和完善，不管表現層如何定義和更改，邏輯層都能完善地提供服務。主要對用戶的請求接受，以及數據的返回。

業務邏輯層(BLL)：主要是針對具體的問題的操做，也能夠理解成對數據層的操做，對數據業務邏輯處理，若是說數據層是積木，那邏輯層就是對這些積木的搭建。

數據訪問層（DAL）：主要看數據層裏面有沒有包含邏輯處理，實際上它的各個函數主要完成各個對數據文件的操做。而沒必要管其餘操做。

在開發人員眼裏，一個業務系統的分層只是技術架構上的，因此會把日誌紀錄、權限管理、數據庫持久化、消息服務等等，把一些能分離出來的儘可能分離出來，而後再把這些東西組合起來，就成了系統幫助層，它們貫徹於整個業務系統。

三層架構是典型事務腳本邏輯結構，一個複雜的業務都在BBL方法體中從頭至尾描述，處理高度複雜的業務顯得無能爲力！！！

估計全部的.NET 程序員都是從這個經典的三層的架構一步一步走過來的。

3、DDD經典分層

DDD：領域驅動設計

TDD：是測試驅動開發 

POEAA：企業應用架構模式

DDD核心思想是由業務問題來控制解決方案的形式從以數據庫爲中心過渡到領域模型爲中心 

下面這個圖是我在《領域驅動設計與模式實戰》書中拍下來的，他徹底詮釋DDD的經典分層。

各層概念：

表現層（Presentation Layer）：圖中的用戶界面層包括用戶接口層，用戶輸入和數據展現。

應用層（Application Layer）：應用層定義系統的業務功能，並指揮領域層中的領域對象實現這些功能。

領域層（Domain Layer）：核心層，實現全部業務邏輯。

基礎設施層（Infrastructure Layer）：提供整個業務系統的基礎服務。

各層在編譯時的類依賴關係以下圖（這是一個很矮矬窮的圖）：

高層模塊不該該依賴於底層模塊，二者都應該依賴於抽象

抽象不該該依賴於細節，細節應該依賴於抽象。

4、ABP分層

上節FirstABP的解決方案：

ABP詳細分層：

咱們從上到下看看都是什麼意思：

表示層

Presentation：

View Models (Javascript)：=

Views (HTML/CSS)：=

Localization,  Navigation, Notifications：多語言，菜單，通知

web：

Web API Controllers：webapi接口

MVC Controllers, OData：OData是什麼我也不知道

應用層（Application）

Application Services：應用服務

DTOs：數據傳輸對象

DTO Mappers：AutoMapper進行實體與DTO之間的映射

Authorization：參數驗證

Session：

Audit Logging：審計日誌

應用層提供一些應用服務（Application Services）方法供展示層調用。一個應用服務方法接收一個DTO(數據傳輸對象)做爲輸入參數，使用這個輸入參數執行特定的領域層操做，並根據須要可返回另外一個DTO。在展示層到領域層之間，不該該接收或返回實體(Entity)對象，應該進行DTO映射。一個應用服務方法一般被認爲是一個工做單元（Unit of Work）。用戶輸入參數的驗證工做也應該在應用層實現。ABP提供了一個基礎架構讓咱們很容易地實現輸入參數有效性驗證。建議使用一種像AutoMapper這樣的工具來進行實體與DTO之間的映射。

領域層（Domain(Core)）

Entities:實體，領域對象，表明業務領域的數據和操做

value objects：實體模型

Repositories：倉儲，用來操做數據庫進行數據存取。倉儲接口在領域層定義，而倉儲的實現類應該寫在基礎設施層。

Domain Services：領域服務，當處理的業務規則跨越兩個（及以上）實體時，應該寫在領域服務方法裏面。

Domain Event：領域事件，在領域層某些特定狀況發生時能夠觸發領域事件，而且在相應地方捕獲並處理它們。

Unit of Work：工做單元，一種設計模式，用於維護一個由已經被修改(如增長、刪除和更新等)的業務對象組成的列表。它負責協調這些業務對象的持久化工做及併發問題。

基礎設施（Infrastructure）

ORM (EntityFramework, NHibernate)：ORM框架，ABP提供了EF和NHibernate支持

DB Migrations：EF Code First建立數據庫用的

Background Jobs：做業調度和自動任務，（相似Quartz.NET）

補充（單頁面應用和多頁面應用）

在單頁面應用中（SPA）,全部的資源都會一次性加載到客戶端（或者只加載核心資源，懶加載其餘資源），全部的後續和服務器的交互都是經過Ajax調用。Html代碼是使用從服務端接收到的數據在客戶端生成的。整個頁面不會刷新，視圖只是在必要時換入換出。有許多的Javascript SPA框架，好比AngularJs，DurandalJs,BackboneJs和EmberJs。ABP可使用它們中的任何一個，可是提供了使用 AngularJs和DurandalJs的樣例。

在多頁面（經典）應用中(MPA)，客戶端向服務端發送請求，服務端代碼（ASP.NET MVC 控制器）從數據庫中獲取數據，而後Razor視圖引擎生成html 代碼。這些編譯後的頁面發回給客戶端顯示。每一個新的頁面都會致使完整頁面的刷新。

SPA和MPA涉及了徹底不一樣的架構。對於後臺管理系統來講，SPA是最好的候選者，另外一方面，博客更適合MPA模型，由於博客渴望被搜索引擎抓取數據。雖然有不少工具可使SPA對於搜索引擎可見，可是目前的通常作法就是使用MPA。

最後

ABP平衡了一些最好的框架或者類庫，除此以外，ABP本身的類和系統也提供了一個很好的用於N層架構Web應用構建的基礎設施，也提供了很輕鬆地建立分層的解決方案的模板，用做應用的起點。

根據分層咱們把項目的類庫用解決方案的文件夾整理下：