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

背景

之前有同事在分享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

posted @ 2019-06-23 12:14 stoneFang 閱讀(...) 評論(...) 編輯 收藏
内蒙古快3开奖结果