目錄
場景分析三：人員組織關係 詳細的分析過程以及考勤的場景分析就不描述了
第二步：找出聚合根，根據實體、值對象與聚合根的依賴關係，建立聚合
領域驅動實踐總結三:具體應用設計分析
領域驅動設計DDD是一種設計思想，它可以同時指導中臺業務建模和微服務設計(中臺本質是業務模型，微服務是業務模型的系統落地)，領域驅動設計強調領域模型和微服務設計的一體性，先有領域模型然後纔有微服務，而不是脫離領域模型來談微服務設計。
微服務拆分困境產生的根本原因:不知道業務或者微服務的邊界到底在什麼地方。
DDD 核心思想:通過領域驅動設計方法定義領域模型，從而確定業務和應用邊界，保證業務模型與代碼模型的一致性。
對於領域驅動設計的學習做的總結主要寫三篇博客，主要包括三部分:基本理論總結與分析、架構分析與代碼設計、具體應用設計分析，主要參考的資料爲極客時間的歐創新架構師的《DDD》實戰，其他參考書籍在文章下方的參考書籍中。
本次主要總結DDD具體應用設計分析：
一、應用項目的基本背景
項目的目標是實現在線請假和考勤管理。功能描述如下：
- 請假人填寫請假單提交審批，根據請假人身份、請假類型和請假天數進行校驗，根據審批規則逐級遞交上級審批，逐級覈批通過則完成審批，否則審批不通過退回申請人。
- 根據考勤規則，覈銷請假數據後，對考勤數據進行校驗，輸出考勤統計。
備註：本想以大視頻業務系統爲背景自己弄一個的，但是時間太緊，暫時還是以歐創新架構師提供的案例做總結和分析理解，後期有時間會自己出一個關於視頻系統的。
二、針對項目進行領域驅動的戰略設計階段
戰略設計採用的方法是事件風暴，包括：產品願景、場景分析、領域建模和微服務拆分等幾個主要過程。
戰略設計是根據用戶旅程分析，找出領域對象和聚合根，對實體和值對象進行聚類組成聚合，劃分限界上下文，建立領域模型的過程。
戰略設計階段建議參與人員：領域專家、業務需求方、產品經理、架構師、項目經理、開發經理和測試經理。
（一）事件風暴確定產品願景
產品願景是對產品頂層價值設計，對產品目標用戶、核心價值、差異化競爭點等信息達成一致，避免產品偏離方向。
事件風暴時，所有參與者針對每一個要點，在貼紙上寫出自己的意見，貼到白板上。
事件風暴主持者會對每個貼紙，討論並對發散的意見進行收斂和統一，形成下面的產品願景圖。其實，也就是讓所有人確定統一的大方向統一語言，我們究竟在幹什麼，目的和意義是什麼等的基本問題。
產品願景分析對於初創系統明確系統建設重點，統一團隊建設目標和建立通用語言是很有價值的。
針對本項目，最後確定的產品願景圖整理成一段文字就是：
爲了滿足內外部人員，他們的在線請假、自動考勤統計和外部人員管理的需求，我們建設這個在線請假考勤系統，它是一個在線請假平臺，可以自動考勤統計。它可以同時支持內外網請假，同時管理內外部人員請假和定期考勤分析，而不像 HR 系統，只管理內部人員，且只能內網使用。我們的產品內外網皆可使用，可實現內外部人員無差異管理。
達到的目的與意義：
通過產品願景分析，項目團隊統一了系統名稱——在線請假考勤系統，明確了項目目標和關鍵功能，與競品（HR）的關鍵差異以及自己的優勢和核心競爭力等。
（二）事件風暴進行業務場景分析
場景分析是從用戶視角出發，探索業務領域中的典型場景，產出領域中需要支撐的場景分類、用例操作以及不同子域之間的依賴關係，用以支撐領域建模。
項目團隊成員一起用事件風暴分析請假和考勤的用戶旅程。
根據不同角色的旅程和場景分析，儘可能全面地梳理從前端操作到後端業務邏輯發生的所有操作、命令、領域事件以及外部依賴關係等信息。
以請假和人員場景作爲示例------------
場景分析一：請假 用戶：請假人
- 請假人登錄系統：從權限微服務獲取請假人信息和權限數據，完成登錄認證。
- 創建請假單：打開請假頁面，選擇請假類型和起始時間，錄入請假信息。保存並創建請假單，提交請假審批。
- 修改請假單：查詢請假單，打開請假頁面，修改請假單，提交請假審批。
- 提交審批：獲取審批規則，根據審批規則，從人員組織關係中獲取審批人，給請假單分配審批人。
場景分析二：審批 用戶：審批人
- 審批人登錄系統：從權限微服務獲取審批人信息和權限數據，完成登錄認證。
- 獲取請假單：獲取審批人名下請假單，選擇請假單。
- 審批：填寫審批意見。
- 逐級審批：如果還需要上級審批，根據審批規則，從人員組織關係中獲取審批人，給請假單分配審批人。重複以上 4 步。最後審批人完成審批。
備註：完成審批後，產生請假審批已通過領域事件。後續有兩個進一步的業務操作：發送請假審批已通過的通知，通知郵件系統告知請假人；將請假數據發送到考勤以便覈銷。
場景分析三：人員組織關係 詳細的分析過程以及考勤的場景分析就不描述了
（三）事件風暴進行領域建模
領域建模是通過對業務和問題域進行分析，建立領域模型。
向上通過限界上下文指導微服務邊界設計，向下通過聚合指導實體對象設計。
領域建模是一個收斂的過程，分三步：
第一步：找出領域實體和值對象等領域對象
根據場景分析，分析並找出發起或產生這些命令或領域事件的實體和值對象，將與實體或值對象有關的命令和事件聚集到實體。
根據場景分析，分析並找出發起或產生這些命令或領域事件的實體和值對象，將與實體或值對象有關的命令和事件聚集到實體。
（注意表達中的名詞和動詞等，名詞往往是實體、值對象等，動詞往往對應着命令的相關行爲）
第二步：找出聚合根，根據實體、值對象與聚合根的依賴關係，建立聚合
定義聚合前，先找出聚合根。
從上面的實體中，我們可以找出“請假單”和“人員”兩個聚合根。然後找出與聚合根緊密依賴的實體和值對象。我們發現審批意見、審批規則和請假單緊密關聯，組織關係和人員緊密關聯。
找出這些實體的關係後，我們發現還有刷卡明細、考勤明細和考勤統計，這幾個實體沒有聚合根。這種情形在領域建模時你會經常遇到，對於這類場景我們需要分情況特殊處理：
- 刷卡明細、考勤明細和考勤統計這幾個實體，它們之間相互獨立，找不出聚合根，不是富領域模型，但它們一起完成考勤業務邏輯，具有很高的業務內聚性。
- 我們將這幾個業務關聯緊密的實體，放在一個考勤聚合內。
- 在微服務設計時，我們依然採用 DDD 的設計和分析方法。由於沒有聚合根來管理聚合內的實體，我們可以用傳統的方法來管理實體。
經過分析，我們建立了請假、人員組織關係和考勤三個聚合。其中請假聚合有請假單、審批意見實體和審批規則等值對象。人員組織關係聚合有人員和組織關係等實體。考勤聚合有刷卡明細、考勤明細和考勤統計等實體。
第三步：根據業務及語義邊界等因素，定義限界上下文
由於人員組織關係聚合與請假聚合，共同完成請假的業務功能，兩者在請假的限界上下文內。
考勤聚合則單獨構成考勤統計限界上下文。
因此我們爲業務劃分請假和考勤統計兩個限界上下文，建立請假和考勤兩個領域模型。
（四）事件風暴進行微服務的拆分
理論上一個限界上下文就可以設計爲一個微服務，但還需要綜合考慮多種外部因素，比如：職責單一性、敏態與穩態業務分離、非功能性需求（如彈性伸縮、版本發佈頻率和安全等要求）、軟件包大小、團隊溝通效率和技術異構等非業務要素。
在這個項目，我們劃分微服務主要考慮職責單一性原則。
因此根據限界上下文就可以拆分爲請假和考勤兩個微服務。其中請假微服務包含人員組織關係和請假兩個聚合，考勤微服務包含考勤聚合。
三、針對項目進行領域驅動的戰術設計階段
戰術設計是根據領域模型進行微服務設計的過程。這個階段主要梳理微服務內的領域對象，梳理領域對象之間的關係，確定它們在代碼模型和分層架構中的位置，建立領域模型與微服務模型的映射關係，以及服務之間的依賴關係。
戰術設計階段建議參與人員：領域專家、產品經理、架構師、項目經理、開發經理和測試經理等。戰術設計包括以下階段：
（一）分析微服務領域對象
在事件風暴基礎上，我們進一步細化領域對象以及它們的關係，補充事件風暴可能遺漏的業務和技術細節：
- 我們分析微服務內應該有哪些服務？
- 服務的分層？
- 應用服務由哪些服務組合和編排完成？
- 領域服務包括哪些實體和實體方法？
- 哪個實體是聚合根？
- 實體有哪些屬性和方法？
- 哪些對象應該設計爲值對象等。
1.具體服務的識別和設計
事件風暴的命令是外部的一些操作和業務行爲，也是微服務對外提供的能力。它往往與微服務的應用服務或者領域服務對應。我們可以將命令作爲服務識別和設計的起點。
具體步驟如下：
- 根據命令設計應用服務，確定應用服務的功能，服務集合，組合和編排方式。服務集合中的服務包括領域服務或其它微服務的應用服務。
- 根據應用服務功能要求設計領域服務，定義領域服務。這裏需要注意：應用服務可能是由多個聚合的領域服務組合而成的。
- 根據領域服務的功能，確定領域服務內的實體以及功能。
- 設計實體基本屬性和方法。
- 考慮領域事件的異步化處理。
以提交審批這個動作爲例，來說明服務的識別和設計。提交審批的大體流程是：
- 根據請假類型和時長，查詢請假審批規則，獲取下一步審批人的角色。
- 根據審批角色從人員組織關係中查詢下一審批人。
- 爲請假單分配審批人，並將審批規則保存至請假單。
通過分析，我們需要在應用層和領域層設計以下服務和方法。
- 應用層：提交審批應用服務。
- 領域層：領域服務有查詢審批規則、修改請假流程信息服務以及根據審批規則查詢審批人服務，分別位於請假和人員組織關係聚合。請假單實體有修改請假流程信息方法，審批規則值對象有查詢審批規則方法。人員實體有根據審批規則查詢審批人方法。下圖是我們分析出來的服務以及它們之間的依賴關係。
2.聚合中的對象分析
在請假單聚合中，聚合根是請假單。
- 請假單經多級審覈後，會產生多條審批意見，爲了方便查詢，我們可以將審批意見設計爲實體。
- 請假審批通過後，會產生請假審批通過的領域事件，因此還會有請假事件實體。
請假聚合有以下實體：審批意見（記錄審批人、審批狀態和審批意見）和請假事件實體。
再來分析一下請假單聚合的值對象。
- 請假人和下一審批人數據來源於人員組織關係聚合中的人員實體，可設計爲值對象。
- 人員類型、請假類型和審批狀態是枚舉值類型，可設計爲值對象。
- 確定請假審批規則後，審批規則也可作爲請假單的值對象。
請假單聚合將包含以下值對象：請假人、人員類型、請假類型、下一審批人、審批狀態和審批規則。
-----------------------------------------------------------------------------------------------------------------------------------------------------
人員組織關係聚合中，我們可以建立人員之間的組織關係，通過組織關係類型找到上級審批領導。
它的聚合根是人員，實體有組織關係（包括組織關係類型和上級審批領導），其中組織關係類型（如項目經理、處長、總經理等）是值對象。上級審批領導來源於人員聚合根，可設計爲值對象。人員組織關係聚合將包含以下值對象：組織關係類型、上級審批領導。
3.微服務內的對象清單
在確定各領域對象的屬性後，我們就可以設計各領域對象在代碼模型中的代碼對象（包括代碼對象的包名、類名和方法名），建立領域對象與代碼對象的一一映射關係了。
根據這種映射關係，相關人員可快速定位到業務邏輯所在的代碼位置。
（二）設計微服務代碼結構
根據 DDD 的代碼模型和各領域對象所在的包、類和方法，可以定義出請假微服務的代碼結構，設計代碼對象。
1.應用層代碼結構
應用層包括：應用服務、DTO 以及事件發佈相關代碼。
在 LeaveApplicationService 類內實現與聚合相關的應用服務，在 LoginApplicationService 封裝外部微服務認證和權限的應用服務。
(提醒一下：如果應用服務邏輯複雜的話，一個應用服務就可以構建一個類，這樣可以避免一個類的代碼過於龐大，不利於維護。)
2.領域層代碼結構
領域層包括一個或多個聚合的實體類、事件實體類、領域服務以及工廠、倉儲相關代碼。
一個聚合對應一個聚合代碼目錄，聚合之間在代碼上完全隔離，聚合之間通過應用層協調。
請假微服務領域層包含請假和人員兩個聚合。人員和請假代碼都放在各自的聚合所在目錄結構的代碼包中。
如果隨着業務發展，人員相關功能需要從請假微服務中拆分出來，我們只需將人員聚合代碼包稍加改造，獨立部署，即可快速發佈爲人員微服務。
（三）後續的工作：詳細設計 + 代碼開發和測試
1. 詳細設計
在完成領域模型和微服務設計後，我們還需要對微服務進行詳細的設計。
主要設計以下內容：實體屬性、數據庫表和字段、實體與數據庫表映射、服務參數規約及功能實現等。
2. 代碼開發和測試
開發人員只需要按照詳細的設計文檔和功能要求，找到業務功能對應的代碼位置，完成代碼開發就可以了。
代碼開發完成後，開發人員要編寫單元測試用例，基於擋板模擬依賴對象完成服務測試。
四、具體代碼參考
本次的總結都是按照極客時間課程《DDD實戰》歐創新架構師的舉例項目來進行的，相關代碼可以克隆其代碼：
https://github.com/ouchuangxin/leave-sample.git
後期在其基礎上會有補充，以及對於視頻系統的項目分析，後續博客中公佈。
參考書籍、文獻和資料
1.極客時間課程《DDD實戰》，歐創新，2019.
2.鄭天民. 微服務設計原理與架構. 北京：人民郵電出版社，2018.