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. 事件通知
當履約單結束時，僅僅表示補償單的履約環節結束了，并不表示整個補償單完結了，補償單與履約單是兩個物體，不能跨越物體，直接在履約單中呼叫補償單的完成行為，同時，履約單完成了，也不需要馬上要求補償單就完成，因此履約單完成后，可發送一個完成事件通知， 補償完成存在兩種情況：- 補償履約單在發起處理時，同步就完成了，
- 補償履約單發起處理后，由下級系統反饋，異步告知補償完成，
- 當通知資訊為履約單處理例外，補償單變更為待溝通狀態；
- 當通知資訊為履約單處理成功，補償單變更為結束狀態；
- 當通知資訊為履約單處理中時，補償單變更為補償中狀態；
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/340311.html
標籤：Java