一次關於聚合根的激烈討論

背景

以前有同事在分享DDD在閒魚商品詳情頁的實踐時，你們對閒魚團隊領域建模關於商品詳情頁的聚合根建模表示不認同。
由於這是面向頁面建模，不是面向領域建模，將微服務拆分和領域建模混爲一談了
因而我以聚合根定義做爲引子，結合組內在實踐DDD過程當中，聚合根隨着業務查詢複雜而致使聚合根不斷膨脹的問題，提出借鑑CQRS讀寫分離的理念，來解這個問題。 詳見DDD-CQRS能解聚合根的問題嗎 引起了你們對領域模型的從新思考和激勵討論。歷經3小時得出了一些結論，達成了共識。

討論過程

一般咱們說領域建模不該該去考慮微服務架構，工程結構，應該專一於業務。
但在實踐過程當中發現這並非一個好的方式，或者說是可落地的。由於業務領域建模完成後，仍是要反映到系統架構中，
最終是要落地到代碼實現，經過代碼來表達出領域模型。因此說咱們的討論不該該是脫離
系統架構的。可是當咱們發現業務領域建模完，經過代碼實踐一段時間後，發現代碼模型腐化了，這時候
咱們首先思考的方向不該該是經過代碼來糾正，而是應該回歸到業務建模。

結論

聚合根

• 聚合根表明的是一個領域邊界
• 聚合根的內容要保證數據一致性（這裏的一致性指的不是數據持久化的事務一致性，而是業務數據的一致性，包含業務上的業務校驗） 好比訂單和訂單詳情，一個沒有訂單詳情的訂單是不完整的
• 聚合根裏面有多少個實體，由領域建模決定
• 永遠不要刪除聚合根
  聚合根之間有引用，若是刪除了聚合根，會致使關聯聚合的數據不一致
  這邊很容易和實體的生命週期從屬於聚合根搞混了。這邊的依賴是關聯依賴，實體依賴聚合根是has a
• 聚合根引用聚合根值id/或者id值對象

實體

• 實體通常從屬於某個聚合根，要否則就能夠定義成聚合根了
• 實體有本身的生命週期，他的生命週期從屬於聚合根。也就是聚合根沒有，實體也就沒了
  好比我能夠對訂單詳情的數據進行編輯，刪除。
• 聚合根與實體的關係一般是1:N
  由於若是是1:1,一般不須要定義實體了。直接放在聚合根裏面，不須要惟一id了。

注意，聚合根裏面沒有實體，並不意味着數據庫就只有一張表，能夠設計成多張表。DB設計和領域建模沒有關係

• 能夠單獨更新聚合根中實體數據
  不是說只能有一個方法saveAggr(),能夠有saveEntity()方法

案例

case 1:

品牌信息和店鋪
店鋪依賴品牌，可是店鋪有本身獨立的生命週期。他們的數據沒有一致性要求。因此店鋪是一個聚合根

case 2: 門店與門店商品

門店商品有本身的價格，返傭。須要單獨編輯，是一個實體。脫離了門店後沒有生命終結。
下期問題
目前咱們只討論了實體類型的聚合根，沒有討論業務過程的聚合根，好比轉帳

關注公衆號【方丈的寺院】，第一時間收到文章的更新，與方丈一塊兒開始技術修行之路

引用

https://www.jianshu.com/p/e6c2fdef8db6