1.背景

為了更全面的說明DDD領域驅動設計相關的知識和技巧，先採用一個案例，通過案例分析，從領域建模，到系統編碼，完整的走一遍領域驅動設計流程。 本例所採用的案例為電商業務中的售後補償系統。基於DDD的模式，實現售後補償功能的設計和開發。 售後補償：使用者下單收到商品後，發現商品存在如包裝，外觀，質量等方面的瑕疵，通過補償申請介面，向電商平臺申請補償的一種業務。常見補償方案如補發紅包，代金卷，金幣，退款，重新補發問題商品等。售後補償簡易流程如下： 特別申明：本文所講案例為實際某平臺的售後補償系統，基於DDD模式重構後，已經發布上線。採用DDD領域驅動設計，對比歷史系統，在系統設計，程式碼規範性，程式碼質量，程式碼理解度方面均有本質的提升。本案例講解做了脫敏處理，簡化部分功能（實際售後補償業務偏複雜），詳情參看以下的需求說明文件。

2.售後補償需求說明

售後補償業務簡易流程如下：

1. 選擇補償方案，生成售後補償單；
2. 補償單審批；
3. 補償單履約處理；
4. 履約單處理完成，補償單完結；

補償申請一共存在三個入口：

1. 客服人員後臺發起售後補償申請；
2. 使用者基於app發起售後補償申請；
3. 線下訂單，特殊補償申請；

三種申請方式入口不同，客戶端傳入的引數不同，但發起資訊均包括以下兩部分：

1. 基礎資訊：補償單的基礎資訊；
2. 補償方案資訊：補償單到底用哪一種補償方案補償，如退款，紅包。

2.1 補償基礎資訊

欄目	說明
基礎資訊	欄位包括：操作人編碼，訂單號，補償原因，責任歸屬（公司原因，供應商原因，物流原因），描述，附件，補償方式（紅包，退款，代金券，補發），補償屬性（商品，非商品），理論補償金額，實際補償金額。其他非關鍵欄位。
校驗	部分欄位的必填驗證(訂單號，操作人編碼，原因編碼，補償方式，責任方歸屬)； 訂單號合規可用（存在，且狀態正常）
業務處理	基於訂單號，獲取訂單明細資訊。 基於操作人編碼，呼叫使用者系統，獲取操作人的型別，區別是使用者還是後臺客服人員。
資料儲存	記錄補償單基礎資訊到相關的資料表。

2.2 補償方案

補償方案	欄目	說明
商品退款	基礎欄位	欄位包括：實際補償值，商品編碼，商品數量，商品理論補償值。
	觸發條件	補償方式不是補發模式； 補償屬性為商品屬性；
	校驗	商品編碼存在訂單中； 商品數量大於零，且商品數量<=原始訂單中該商品的商品數量； 商品理論補償值必須大於等於零； 實際補償值必須大於零；
	業務處理	彙總明細中的商品補償金額，記錄到補償單基礎資訊中。補償單基礎資訊的理論金額，實際補償金額為商品明細中合計資料。
	資料儲存	記錄補償策略資訊到相關資料表中。
非商品 其他補償	基礎欄位	欄位包括：實際補償值，理論補償值。
	觸發條件	補償方式不是補發模式； 補償屬性為非商品屬性；
	校驗	商品理論補償值必須大於等於零； 實際補償值必須大於零；
	資料儲存	記錄補償策略資訊到相關資料表中。
補發補償	基礎欄位	補償商品編碼,發貨倉庫編碼，補償數量
	觸發條件	補償方式是補發模式；
	校驗	補償商品編碼必須存在 補償數量必須大於零； 發貨倉庫編碼不能為空； 補償商品在商品系統中存在； 補償商品的庫存大於等於補償數量；
	業務處理	基於傳入的商品編碼資訊，獲取對應的庫存資訊。 補償單基礎資訊的理論金額，實際補償金額為補發商品明細中合計資料。
	資料儲存	記錄補償策略資訊到相關資料表中。

2.3 補償單審批

1. 自動審批：申請人員型別為後臺管理人員時，自動審批通過。
2. 手動審批：申請人員型別為電商平臺使用者時，需相關的管理人員手動審批後，才能繼續走流程處理。

2.4 補償單其他資訊完善

1. 補傳補償圖片資訊：在補償單處理過程中，系統支援使用者重新錄入補傳圖片資訊。
2. 填寫備註資訊：在補償單處理過程中，支援相關的操作人員填寫備註資訊。
3. 補償單終止：在補償單未發起處理或處理失敗時，支援終止補償單，作廢該筆補償申請資訊。
4. 重新發起補償：補償履約處理失敗後，再次發起處理；

2.5 售後補償履約處理

1. 補發處理：補償策略為補發補償時，重新補發商品，呼叫訂單中心介面，建立一個新的訂單。補發處理不能馬上獲取補發的訂單是否已經出庫了，需非同步等待訂單系統回覆資訊。
2. 商品退款處理：補償模式為商品原因並退款時，呼叫退款系統，申請退款。退款是一個非同步過程，需等待退款系統回覆資訊。
3. 商品其他模式退款處理：如紅包，代金券等直接呼叫使用者中心介面請求處理，能同步得到系統的處理結果。