DDD領域驅動設計-案例需求文檔-Ⅱ

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. 商品其他模式退款處理：如紅包，代金券等直接調用用戶中心接口請求處理，能同步得到系統的處理結果。