從壹開始微服務 [ DDD ] 之一 ║ D3模式設計初探與個人計劃書

時間 2019-11-05

原文原文鏈接

緣起

哈嘍你們週四好！又是開心的一天，時間過的真快，咱們的《從壹開始 .net core 2.1 + vue 2.5 》先後端分離系列共 34 篇已經完結了，固然之後確定還會有更新和修改，直接在文章內更新，並在文章開頭作提醒，若是有大的改動或者新功能，會在目錄頁進行重點說明（可能簡書的更新速度沒有博客園快，若是有任何疑問，能夠先看博客園的文章，就是上邊的這個地址👆）。若是你是剛看到個人文章，並且剛好對.net core 不是很明白，或者想了解下如何先後端徹底分離的，能夠先看看上一個系列，我已經把 .net core 和 vue 的內容明顯分開了，同時也把 vue 的基礎部分和入門教程兩個部分進行說明，相信你們都能看的明白。html

　　關於這一個系列，我想了好久，原本想開下 React 系列的，可是羣裏的小夥伴的反映，.net 後端還有不少東西，並且好多小夥伴反映課本太苦澀，看不進去，文檔又太少，國內的大神好像也不太照顧咱們這些小學生，特別是不多經過代碼的形式講解，那因此我就開了這個系列，雖然感受會坎坷波折，本系列會從一個空的 Solution 到一個完整 Project 的過程，具體的會在下邊的計劃書中詳細說明，你們能夠一下子瞭解下，固然，框架原本就很見仁見智，思想設計更是沒有常規法去定義，可能會有人不一樣意，老張但願若是有不一樣意見，別僅僅只是點擊一下反對，能夠發表下評論嘛，也算是給 .net 生存環境作點兒貢獻，固然這個是練習項目，實際狀況還要按照公司的要求來寫，甚至公司都用不到（可是可能會面試的時候問到），一些小夥伴就會問，那我爲啥要學，嗯~~~要是這麼問，我也不知道如何回答了 [苦笑] ，就好像健身同樣。前端

　　我給這個項目取名：ChristD3，意思是聖誕節DDD，但願到聖誕節的時候能夠完結，由於年末手中工做比較多，因此不會天天都寫，可是每週確定會有更新，也但願你們能夠多多提意見，爲了.net 的生存環境點贊加油吧！其實若是你已經開完了我寫的上一個系列，你會發現其實上一個系列已經有 DDD 的影子了，不信？看完本文你就會知道了。vue

簡單強調：git

一、本系列重點經過代碼進行說明，那些苦澀的概念可能比較少，特別是本文，是簡要說明，具體的詳細內容在以後文章中體現。github

二、本系列只是對知識點進行講解，重點在說明新知識上，只是一個很小的框架，數據也很簡單，可能仍是一個簡單的我的博客之類的，請不要和企業級項目對比。web

三、本系列仍是沿用上一個系列的宗旨：旨在拋磚引玉，想要學會還得本身多思考，文中會有兩本參考書，能夠看看。面試

1、今天要實現紅色的部分

2、DDD領域驅動設計的前世此生

好多小夥伴都在說，聽DDD都聽了好幾年了，感受就像是空氣同樣，一直在身邊，但是一直摸不着，雖然有時候用到一些，可都是沒法具體深刻的對其描述和總結，那領域驅動設計究竟是怎麼來的呢，在早期項目開發中，咱們主要就是單系統來進行開發，不少的模板都是揉在一塊兒，其實如今我們平時用的最多的MVC架構也有這樣的問題，而後近來演化出的先後端分離，是從協同開發的角度方向去改善單系統問題，而DDD則是從後端總體框架中，對項目進行整合，剝離，細分和聯繫通信等等，這樣面向領域驅動設計就出現了。

一、DDD領域驅動設計知多少

首先要知道DDD是一種開發理念，核心是維護一個反應領域概念的模型（領域模型是軟件最核心的部分，反應了軟件的業務本質），而後經過大量模式來指導模型設計與開發。

DDD的通常過程是：首先經過軟件需求規格說明書或原型生成一個領域模型（類、類的屬性、類與類之間的關係）；而後根據模式（應該如何分層？、領域邏輯寫在哪？與持久化如何交互？如何協調多對象領域邏輯？如何實現邏輯與數據存儲解耦等）指導來實現代碼模型。

DDD中最核心的是Domain Model（領域模型），和領域模型相對的是事務腳本。領域模型和事務腳本說到底就是面向對象和麪向過程的區別。

若是感受上邊的理解有點兒苦澀，這裏舉個栗子：

我認爲任何一個系統都會屬於某個特定的領域，好比論壇是一個領域，只要你想作一個論壇，那這個論壇的核心業務是肯定的，好比都有用戶發帖、回帖等核心基本功能。好比電商平臺、普通電商系統，這種都屬於網上電商領域，只要是這個領域的系統，那都有商品瀏覽、購物車、下單、減庫存、付款交易等核心環節。因此，同一個領域的系統都具備相同的核心業務，由於他們要解決的問題的本質是相似的。

所以，咱們能夠推斷出，一個領域本質上能夠理解爲就是一個問題域，只要是同一個領域，那問題域就相同。因此，只要咱們肯定了系統所屬的領域，那這個系統的核心業務，即要解決的關鍵問題、問題的範圍邊界就基本肯定了。

關於電商系統你們確定都很瞭解了，什麼商品模塊，用戶模板，訂單模板，等等等等，這個就是領域模型的一個體現，網上看到一個很好的文章，他對普通電商的訂單中心進行建模，如圖：

二、領域驅動設計總體架構

那從總體架構上來講，主要分紅如下四個部分，具體的在下一講的項目總體搭建中會詳細說明：

Presentation Layer：表現層，負責顯示和接受輸入；

Application Layer(Service)：應用層，很薄的一層，只包含工做流控制邏輯，不包含業務邏輯；

Domain Layer(Domain)：領域層，包含整個應用的全部業務邏輯；

Infrastructure Layer：基礎層，提供整個應用的基礎服務；

DDD領域驅動設計的優勢就包括：

1.從技術維度實現分層：可以在每層關注本身的事情，好比領域層關注業務邏輯的事情，倉儲關注持久化數據的事情，應用服務層關注用例的事情，接口層關注暴露給前端的事情。

2.業務維度：經過將大系統劃分層多個上下文，可讓不一樣團隊和不一樣人只關注當前上下文的開發。

3.時間維度：經過敏捷式迭代快速驗證，快速修正。

三、如何劃分領域聚合

這裏隨便舉個栗子：

公司部門權限小系統，用戶表 User、角色表 Role、用戶角色關係表 UserRole、部門表 Department、菜單表 Menu、菜單角色關係表 MenuRole，共六個表，

首先呢，根據個人想法，只要對一個模型操做，就必須建倉儲 Repository ，那它就是一個聚合，因此：聚合和倉儲基本是一對一的，有一個倉儲就是一個聚合。

因此如今有四個聚合了：

聚合1：Department

聚合2：Menu、MenuRole、Role 三個，聚合根是 Menu

聚合3：User、UserRole、Department、Role 四個，聚合根是 User。

聚合4：Role、User、UserRole、MenuRole、Menu 五個，聚合根是 Role。

而後再從關係表中看，用戶和角色是多對多的關係，因此須要把 UserRole 做爲一個新的聚合

聚合5：UserRole、User、Role 三個，聚合根是 UserRole

這裏存個疑，MenuRole 需不須要一個倉儲，也就是一個聚合？

四、有哪些資料能夠參考

書籍：

2004年，Eric Evans的《領域驅動設計——軟件核心複雜性應對之道》

2014年，Vaughn Vernon的《實現領域驅動設計》，我的推薦

編者按：
一、本項目我是借鑑了 https://github.com/EduardoPires/EquinoxProject 來說解的，請支持原做者！由於他沒有文檔，因此我就寫了這個系列。

二、可能你會說我是抄襲，可是我本身寫的時候，結構不是這樣的，我當時是這麼寫的（若是你和我下邊的分層同樣，那就證實我不是瞎說的了）：

應用層：除了Service和IService、DTO、還有使用 CQRS 方法的查詢、接受的命令，事件驅動的通訊（集成事件），可是沒有業務規則；
領域層：這裏主要放的是領域實體、值對象、聚合和事件模型、Bus等；
基礎層：就是ORM的持久化相關；
U I 層：顯示頁面；

不過我寫的時候感受凌亂，不適合你們初學者學習，因此就想着要改變一下，對比了Git上的各類大神結構，偶然發現了EduardoPires的代碼，感受很清晰，就按照他這個來了。

感謝如下文章對本系列的幫助：

一、特別鳴謝開源項目

https://github.com/EduardoPires/EquinoxProject，我基本都是在這個項目基礎上，爲了廣大剛進入DDD的小夥伴的，由於直接看項目確定看不懂。我重新建空解決方案開始，一點一點講解的，作了這個系列說明文檔，我要強調我是主要講知識，Code仍是要尊重原做者，可是個人核心是佈道，是對他的項目講解，由於沒有Code，我也能講知識點。

二、感謝平時遇到的特別好的文章（節選）

三、固然還有平時爭議最多的話題：

Repository 倉儲，你的歸宿究竟在哪

3、個人計劃書中涉及到的相關知識

Bingo：這裏是個人一個初步設想，之後可能根據狀況進行增刪，其中不少我們在以前的項目裏都已經說到了，到時候會簡單說一下跳過，也正好溫習下，好比 WebApi的建立，依賴注入的使用，Dto數據傳輸對象的概念，Swagger 接口文檔的使用，這些你們是否是很熟悉，因此說，當時在寫上一個項目的時候，已經用了一部分DDD的思想了，如今回想起來是否是感受本身棒棒噠。至於不懂或者沒見過的，不要緊，之後都會懂得的。