領域驅動設計DDD實戰進階第一波(三)：開發通常業務的大健康行業直銷系統（搭建支持DDD的輕量級框架二）

瞭解了DDD的好處與基本的核心組件後，咱們先不急着進入支持DDD思想的輕量級框架開發，也不急於直銷系統需求分析和具體代碼實現，咱們還少一塊，那就是經典DDD的架構，只有瞭解了經典DDD的架構，你才能知道具體在哪層要實現哪些功能，編寫哪些代碼，具體在開發DDD的輕量級框架與具體模塊代碼實現時，才能作到有的放矢。

在這裏須要說明的是，咱們的大健康行業直銷系統有必定的業務複雜性，沒有高併發、高性能的需求，因此不管是經銷商上下文、產品上下文仍是訂單上下文的具體實現，咱們都將遵循經典DDD架構，而不是CRUD簡單方式或CQRS DDD架構的方式。

傳統三層架構以及問題：

問題：
1.過度注重數據訪問層，而不重視領域。
2.業務邏輯直接與數據訪問層耦合，與領域爲核心的DDD思想背道而馳。
3.沒有一系列的模式與方法論指導這種分層架構的開發約束。

經典DDD架構：

1.基礎結構層：整個產品或系統的底層支撐

a.經常使用工具、支撐功能：這個.netcore項目至少要實現如下的功能：Json配置文件的讀取、WebApi返回給前端的基本格式對象的定義、Json序列化與反序列化、加密功能、依賴注入框架的二次封裝等。

b.支持DDD框架：這個.net core 項目至少要實現如下的功能：聚合根接口定義、實體接口定義、值對象接口定義、倉儲接口定義、倉儲接口的EF Core頂層實現（工做單元模式）。

c.聚合根倉儲實現：這個.netcore項目嚴格來說其實不屬於基礎結構層部分，只是因爲習慣，把它放到基礎結構層這個解決方案文件夾中。它實際上是引用了領域層的領域對象，而且 從領域層對應的聚合根倉儲接口中繼承，而後實現領域對象持久化到數據庫，這樣，倉儲實現是依賴衣領對象，領域對象與領域邏輯就不須要依賴倉儲。領域模型纔是系統真正的核心。

2.領域層：界限上下文的領域邏輯

a.首先要實現這個界限上下文的領域對象的POCO模型。

b.而後針對這個界限上下文的全部領域對象，創建每一個領域對象本身的業務邏輯，注意的是，領域對象的業務邏輯最好不與倉儲直接發生交互，就算領域邏輯要臨時查詢數據庫也不要這樣。

c.定義該界限上下文聚合根的倉儲接口，這個接口表明的是聚合根與持久化打交道的基礎約束，具體實現仍是在基礎結構層的聚合根倉儲中實現，這樣就實現瞭解耦。把聚合根倉儲接口定義在領域層的意義是能夠爲領域層的調用方-應用服務層的用例提供對聚合持久化支持。

d.定義該界限上下文的EF Core上下文接口並實現，這樣就經過映射關係，EF Core就能夠處理領域對象與數據庫表之間的映射了。

3.應用服務層：界限上下文的用例

a.某個上下文的應用服務層的某個用例，經過調用領域對象的領域邏輯，完成相關領域邏輯的實現

b.領域邏輯完成後，應用服務層用例調用領域層的聚合根的倉儲接口的方法，完成領域對象的預持久化。（應用服務經過基礎結構層的依賴注入框架與Json配置文件找到聚合根倉儲接口對應的實現）

c.應用服務層用例而後調用基礎結構層的EFCore倉儲接口的工做單元方式，完成真正的持久化。（應用服務經過基礎接口層的依賴注入框架與Json配置文件找到頂層倉儲接口對應的工做單元實現）

d.用例返回給接口層須要的前端所需的json對象格式。

4.接口層：很是薄的一層

a.只須要調用應用服務層用例

b.向前端返回所需的json對象格式

從上述架構特色能夠看出，聚合根的倉儲與領域邏輯徹底解耦，是經過應用服務層的用例將他們協調起來完成功能。

DDD實戰進階視頻請關注微信公衆號：MSSHCJ