背景
領域驅動中關于聚合設計的原則一直存在一個模糊的定義,比如:不變量、一致性和一個邊界。根據這些規則很難清晰的劃分聚合,不排除聚合的設計有一定的藝術性,但是在限定的領域內或許有某種可以明確遵循的規則,前幾天我好像思考到了這樣一個規則,這里分享給大家,跪求批評。
規則(在基于關系數據庫的領域,聚合的邊界等于并發管理的邊界。)
為了滿足不變量和一致性,毫無疑問我們要采用并發管理。
正確的聚合設計
下圖中只有一個聚合實例,在聚合根中應用樂觀鎖保證聚合的一致性,一個聚合必須做為一個整體進行操作,如:客戶端修改“明細”時,其加載和保存的JSON數據必須包含“聚合根”。
錯誤的聚合設計
下圖中只有三個聚合實例,在聚合根中應用樂觀鎖保證聚合的一致性(注意是三個聚合),因為每個聚合都可以獨立的操作,因此很難保證概念的一致性(明細的權重之和等于100%),比如:假如目前明細的權重之和還差10%,兩個人同時添加一個10%的明細。這種設計不是不能保證概念的一致性,是需要額外的成本,如上面的問題:采用雙驗證(插入前后都進行一次驗證)。
正確的聚合設計
多數對象之間不存在并發管理的需要(獨自還是有這個需求的),像文章和評論之間是沒有任何并發管理需求的,你不期望A發表評論的時候B就不能發表了或者你修改文章的時候別人不能發表評論了。
備注
聚合的設計也就是領域模型的設計是DDD的重點,我也沒有太多經驗可言(失敗的倒是有),希望朋友們多給意見。
?
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索:z360901061

微信掃一掃加我為好友
QQ號聯系: 360901061
您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對您有幫助就好】元
