DDD領域驅動設計-案例建模設計-Ⅲ
1. 背景
參考《DDD領域驅動設計-案例需求文檔》，本文將構建實體，聚合根詳述領域驅動中的建模設計。構建實體，聚合根的一些原則或方法，將在後續文章中說明。
2. 建模設計
2.1. 實體建模
參考售後補償需求文檔，對售後補償業務做領域建模。現規劃如下：
2.1.1. 補償單聚合跟
補償單聚合根主要是針對業務中，用戶通過不同的場景創建補償單的過程。如售後管理人員，客服人員通過後端管理系統發起補償申請，電商用戶通過app發起售後補償申請。補償單聚合根具有申請，修改狀態，修改補償資訊等行為，整個過程在領域層做業務實現，最終通過倉庫層落地到資料庫。補償聚合根的唯一標識為補償單號，該補償單號最終會落地到數據表中。補償單聚合根具體組成屬性如下圖（右鍵圖片，在新標籤頁中查看，可查看完整大圖）：
2.1.1.1. 補償單實體
本例中的補償單實體就是補償單聚合根。他包括補償單基礎資訊和補償單方案資訊。這裡的補償單基礎資訊和補償單方案類似於訂單資訊和訂單明細的關係，即一個為整體一個為部分。整體與部分具有共同的生命周期。部分依賴於整體，所以補償方案與補償單是一種組合的關係。
2.1.1.2. 補償策略實體
補償策略依賴於補償單，拋開具體的補償單，單獨的補償策略在系統中是不能獨立存在的。補償策略設置為一個實體，它是補償單聚合根的一部分。補償策略實體不能與補償單實體分開，這兩個實體中，補償策略的資訊，又會影響到補償單實體的資訊，如補償策略為商品退款模式，補償商品的總金額也要記錄到補償單實體的資訊中。
一個策略實體由具體的補償方案組成，分別為商品補償策略實體，補發補償策略實體，非商品補償策略值對象三個方案中的一個方案組成（有且僅有一個）。因此策略實體於具體的子策略方案是一種聚合的關係。
2.1.1.3. 商品退款子實體
售後原因為商品原因導致的，針對這樣的情況，為客服做補償處理（不補發商品，可通過其他補償如紅包，代金卷），一個補償單是基於訂單的，一個訂單存在多個商品的情況，因此一個補償單存在多個商品需要補償的情況。
2.1.1.4. 補發補償子實體
最終對用戶的補償方案為補發商品。補發商品存在補發多個商品的情況。（補發與非補發，業務場景不同，需要的參數不同，是兩個獨立的實體）。
2.1.1.5. 非商品特殊補償值對象
補償的原因不是商品導致的，其他原因直接做的商品補償。不補發商品，可通過其他補償如紅包，代金卷等放鬆補償。
2.1.2. 售後履約單聚合根
售後履約單是售後補償單的下游單據，當補償單審批通過後，就開始真正執行補償履約的功能了。補償處理過程較長，有自己的生命周期，與補償單的生命周期不一樣，設置售後履約單聚合根，便於維護補償過程中的資訊。一個履約單在處理過程中，可能非同步接收下級系統回饋的資訊，將下級系統回饋的資訊設置為履約單的值對象資訊。履約單聚合根具體組成屬性如下圖（右鍵圖片，在新標籤頁中查看，可查看完整大圖）：
2.1.2.1. 創建訂單回饋值對象
補償處理模式為補發時，會調用訂單系統創建訂單，訂單系統又會基於消息通知售後補償系統訂單出庫了。建立訂單回饋值對象，用於接收訂單創建成功時的消息。
2.1.2.2. 創建退款回饋值對象
補償處理模式為商品補償時，會調用支付系統發起退款，支付系統又會基於消息通知售後補償系統退款的結果。建立退款回饋值對象，用於接收退款處理的消息。
2.2. 領域服務
實體行為的具體邏輯實現，單獨編寫一個實現類，這種類在DDD里被叫做領域服務（Domain Service）。
2.2.1. 補償單聚合根領域服務設計
售後補償單聚合根中，對於行為中簡單的邏輯，如修改責任方資訊，設置單據終止等直接在領域服務中編寫實現邏輯程式碼。對於存在多個分支，複雜的情況如審批，保存，應基於面向對象編程思維，採用介面的模式完成功能。
例如：補償聚合根保存時，補償方案不同，保存的數據不同，判斷的邏輯不同，應該將補償策略資訊單獨抽象出來，在領域服務中，完善補償策略資訊。可根據策略設計模式，把可能導致分支變化的模組獨立出來，基於介面編程，便於後續功能擴展和維護。
補償單聚合根領域服務實現類圖參考如下（右鍵圖片，在新標籤頁中查看，可查看完整大圖）：
2.2.2. 履約單聚合根領域服務設計
補償履約單是補償單的下級單據，當補償單據審批通過後，就創建補償履約單。補償履約單有自己的行為和生命周期。
補償履約單處理過程中，失敗時，僅修改履約單的單據狀態，補償完成時，也只修改履約單的單據狀態。（不可在補償履約聚合根中，直接操作補償單聚合根修改補償單的狀態）。
售後補償處理：調用售後履約單聚合根的處理行為，處理結果分為三種：
- 處理通過：這種是履約單調用下級系統，可以同步得到處理結果（成功或失敗）。
- 處理中：履約單調用下級系統，是一個非同步的回復過程。只有等下級單回饋後，才可以做補償完成。處理中狀態，設置履約單狀態為處理中。
- 處理異常：履約單處理過程發生異常，記錄補償履約待溝通記錄。
補償處理場景舉例如：
- 履約單處理為補發訂單時，發起處理並不能馬上得到處理的結果。針對這樣的情況，為履約單設計一個接受下級回饋的行為。
- 履約單處理為其他模式補償處理時，發起處理可以同步得到處理結果。基於介面編程，頂級介面設置了接受下級回饋函數（設置一個默認的default方法），實現類可不實現下級回饋函數。
履約單聚合根領域服務實現類圖參考如下（右鍵圖片，在新標籤頁中查看，可查看完整大圖）：
2.3. 事件通知
當履約單結束時，僅僅表示補償單的履約環節結束了，並不表示整個補償單完結了。補償單與履約單是兩個實體，不能跨越實體，直接在履約單中調用補償單的完成行為。同時，履約單完成了，也不需要馬上要求補償單就完成，因此履約單完成後，可發送一個完成事件通知。
補償完成存在兩種情況：
- 補償履約單在發起處理時，同步就完成了。
- 補償履約單發起處理後，由下級系統回饋，非同步告知補償完成。
履約處理後，只更新履約單的狀態。發布一個履約單事件，通知其他實體做對應的業務處理。參考事件通知的模式，基於Spring Event事件通知機制，做履約單後續的副作用業務處理（未採用領域事件模式，該模式還存在不完善的地方，採用Spring Event穩定可靠）。
履約單完成後，發送事件，補償單監聽事件，做後續業務處理：
- 當通知資訊為履約單處理異常，補償單變更為待溝通狀態；
- 當通知資訊為履約單處理成功，補償單變更為結束狀態；
- 當通知資訊為履約單處理中時，補償單變更為補償中狀態；
