背景
領域驅動中關于聚合設計的原則一直存在一個模糊的定義，比如：不變量、一致性和一個邊界。根據這些規則很難清晰的劃分聚合，不排除聚合的設計有一定的藝術性，但是在限定的領域內或許有某種可以明確遵循的規則，前幾天我好像思考到了這樣一個規則，這里分享給大家，跪求批評。
規則（在基于關系數據庫的領域，聚合的邊界等于并發管理的邊界。）
為了滿足不變量和一致性，毫無疑問我們要采用并發管理。
正確的聚合設計
下圖中只有一個聚合實例，在聚合根中應用樂觀鎖保證聚合的一致性，一個聚合必須做為一個整體進行操作，如：客戶端修改“明細”時，其加載和保存的JSON數據必須包含“聚合根”。
錯誤的聚合設計
下圖中只有三個聚合實例，在聚合根中應用樂觀鎖保證聚合的一致性（注意是三個聚合），因為每個聚合都可以獨立的操作，因此很難保證概念的一致性（明細的權重之和等于100%），比如：假如目前明細的權重之和還差10%，兩個人同時添加一個10%的明細。這種設計不是不能保證概念的一致性，是需要額外的成本，如上面的問題：采用雙驗證（插入前后都進行一次驗證）。
正確的聚合設計
多數對象之間不存在并發管理的需要（獨自還是有這個需求的），像文章和評論之間是沒有任何并發管理需求的，你不期望A發表評論的時候B就不能發表了或者你修改文章的時候別人不能發表評論了。
備注
聚合的設計也就是領域模型的設計是DDD的重點，我也沒有太多經驗可言（失敗的倒是有），希望朋友們多給意見。
?
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
