淺談 DDD 中的聚合
在我看來並不是 MVC 的基礎上增加領域層，使用充血模型，解耦基礎服務，我的代碼就符合 DDD 了。
爲什麼要使用 DDD？
DDD 分爲戰略部分跟戰術部分，相信大家都認同 DDD 的核心在戰略而非戰術。而戰略方面的核心我認爲在業務建模，領域劃分、統一語言等都在爲業務建模服務。
爲什麼業務建模重要?
以前的開發流程有什麼問題？
先說結論，開發人員交付的程序對業務方，產品人員，測試人員來說就是一個黑盒子。除了開發人員自己，沒人知道盒子裏有什麼。當新的需求加入來，需求方，產品人員，甚至測試人員都認爲可行，開發人員卻給出相反結論。
回顧一下以前的開發流程 大致可以歸結爲以下步驟：(開發跟測試人員最好能參與需求分析)
-
業務方描述抽象需求
-
產品將需求轉化爲可落地的產品 (需求具像化, PRD)
-
開發人員根據產品的 PRD 開發
-
測試人員根據產品的 PRD 測試
-
產品人員驗收
-
業務方驗收
依照經驗來說, 在整個流程中開發人員是耗時最長的。與此同時測試人員可能在編寫測試用例，而業務方跟產品人員在這段時間內是阻塞的。最終的程序質量靠測試人員來保障。
開發人員完成開發後:
測試人員關注測試用例是否通過。
產品人員確認展現出來的功能是否符合當初的 PRD。
業務方確認程序是否符合預期。
舉一個我開發項目的例子
一個審批系統
產品的 PRD 描述了一個三層模型：
流程實例, 流程節點, 審批任務。流程實例啓動創建審批節點，審批節點觸發審批任務，任務完成創建下一個節點...。
我是這樣做的：
流程實例, 審批任務。流程實例啓動創建 (一批) 審批任務, 任務被完成後創建後續任務或者流程結束。至於流程節點不存在，不是問題，從任務中提取信息虛擬一個出來。
第一版交付完成。
產品在第一版後追加需求
流程節點可以被非審批人評論。
我....
當時業務方，產品，測試都認爲這是一個合理的需求。只有我一臉懵，因爲我的程序中沒有流程節點這個東西，需求又不能拒絕，無奈給出一個遠超他們預期的開發計劃。
gap 就出在 他們認爲流程節點是一個確實存在的東西，而只有我知道這節點是虛擬的，沒有標識，不能跟其他信息做關聯。
業務建模怎麼解決這個黑盒子問題？
DDD 引入了業務專家這個角色 (在我看來就是業務方，產品)。
-
假設業務專家聽不懂 什麼叫類，什麼是方法，設計模式，他只知道他的業務，兩方人馬完全不在同一頻道，這個時候就需要 “明確上下文”，“統一語言” 了。(不僅僅開發人員與業務專家達成了共識，也包含整個開發團隊達成共識)
-
業務建模，用例分析法、事件風暴、四色建模等看看開始整上。最終達到劃分領域，識別聚合的目的。
-
業務建模落地。開發人員開發過程中，應遵守已經建立的業務模型來編寫代碼。
至此終於實現了，業務專家可通過業務模型窺探到開發人員的代碼實現。統一語言、業務模型在業務專家跟開發人員中間充當了溝通的橋樑。(有點像適配器)
當追加新的需求時，業務專家能合理評估需求的可行性。
讓非開發人員參與到開發中
統一語言，業務建模，模型充血（OOP）。這一系列手段都是爲了實現讓非開發人員參與到開發中這一最終目的。與其說 DDD 是一種架構，不如認爲他是指導開發的方法論。
好比蓋房子，以前只要把房子交付了能住人就行。現在業務專家是設計師，業務模型是設計圖，代碼則是建材，程序員就是工地搬磚的，蓋起來的房子得跟設計師給出的設計圖一樣。
業務模型落地的問題？
這是一個讓我糾結的問題。我感覺還沒有找到符合我期望的答案。
業務模型具現到代碼中，就是一個個聚合。這些聚合符合 OOP 的思想，通過聚合根，實體，值對象的組合來表達業務模型。
以網絡上常見的 demo 爲例：
//訂單明細實體
public class OrderItemEntity {
//id
private Long id;
//商品(值對象)
private Product product;
//數量(值對象)
private Count count;
// item總價(值對象)
private ItemAmount itemAmt;
public void modifyCount(Count count) {
this.count = count;
this.itemAmt = new ItemAmt(this.product.getPrice()*count.get());
}
}
//訂單聚合根
public class OrderAggregate {
//聚合唯一標識
private Long id;
//訂單號(值對象)
private OrderNo orderNo;
//總價 (值對象)
private Amount amt;
//訂單明細
private List<OrderItemEntity> items;
public void modifyItemCount(Product product,Count count) {
//找到商品
this.items.stream().filter(product::equals).findAny().get();
//修改數量 返回Item總價
item.modifyCount(count);
ItemAmount itemAmt = item.getItemAmt();
//修改訂單總價
this.amt = new Amount(this.amt.get()+itemAmt.get());
}
}
//要訂單明細中 名稱叫電腦的商品數量修改100
Product product = new Product("電腦");
Count count = new Count(100);
Amount amt = orderAggregate.modifyItemCount(product, count);理論與現實的矛盾
從代碼上可以看出這一段 1:n 關係的代碼完全基於內存，非常的 OOP，也就是說，我們在獲得 orderAggregate 時，已經加載整個聚合 (包括 List)，這裏就隱含了一個條件內存無限大。
假設 OrderItemEntity 的量級是十萬級，百萬級，明顯這段代碼是不能上線的，理論與現實出現了矛盾。
諮詢了很多大佬 + 個人理解（以下方法爲我自己命名）
模型提升法（無限套娃）
大佬建議:
“如果真有這種場景，就需要調整聚合，比如: 將 OrderItem 提升爲 Order, Order 提升爲 BatchOrder”
思路：
創建 BatchOrderAggregate,BatchOrderAggregate 持有 OrderEntity。
創建 OrderAggregate 持有部分 OrderItemEntity，通過分治的方式化整爲零。
思考：
整體上符合業務模型，而且沒有上限，即如果 BatchOrderAggregate 不能解決問題，那就祭出 BatchBatchOrderAggregate。
BatchBatchOrderAggregate 持有 BatchOrderEntity。
BatchOrderAggregate 持有 OrderEntity。
OrderAggregate 持有部分 OrderItemEntity。
持有倉儲法
（隱藏了數據庫查詢，但是直覺上有點反模式）
大佬建議：
“聚合中構建索引，需要時再加載置換”
思路：
聚合根持有存儲引用，需要時加載到內存中。
可以加入一層接口隔離。
public class OrderAggregate {
//聚合唯一標識
private Long id;
//訂單號(值對象)
private OrderNo orderNo;
//總價 (值對象)
private Amount amt;
//關聯對象接口（接口實現在基礎服務層，在實現中操作數據庫）
private OrderItemRel orderItemRel;
public void modifyItemCount(Product product,Count count) {
List<OrderItemEntity> items = orderItemRel.find(product);
//找到商品
OrderItemEntity item = items.stream().filter(product::equals).findAny().get();
//修改數量 返回Item總價 這裏有分支,item修改是否應該在modifyCount中持久化
//1.modifyCount中持久化item那麼數據庫事務將被加載AppcationService層，容易產生大事務問題。
//2.modifyCount中不持久化item
//2.1寫入消息總線，當OrderAggregate通過Reponsitory持久化時刷出消息持久化
//2.2 OrderAggregate中增加List<OrderItemEntity> items,modifyCount將item加入items。
item.modifyCount(count);
ItemAmount itemAmt = item.getItemAmt();
//修改訂單總價
this.amt = new Amount(this.amt.get()+itemAmt.get());
return this.amt;
}
}自我催眠法
思考：
“持有倉儲法” 思路, 實現也一致，覺得反模式的原因是: 聚合中含有數據庫操作，有耦合基礎服務的嫌疑。
但是換個方向去想：
內存也是存儲介質，數據庫也是存儲介質，二者本來沒有質的區別。二者相比只是對於內存操作, 編程語言直接提供了 API，而數據庫訪問需要依賴第三方庫進行額外編碼，假使能將數據庫操作封裝至跟內存操作一樣自然，那麼不是不可以讓人接受。
Id 關聯法
（感覺上不太符合我的預期，有代碼實現跟業務建模脫鉤，耦合基礎服務的嫌疑。容易退化爲 MVC，此句屬於本人主觀臆斷）
大佬建議：
“對 ddd 理解，不能固化。聚合，本意是解決業務操作的一致性。大量文章，都表述爲一次性加載，實操中是不現實的。解決 “業務操作一致性”，走 “id 關聯 + 內聚到一個函數 + 事務控制”，就很好。”
“沒有必要強行 ddd，拆分開也沒有什麼問題，通過 id 關聯就可以。”
“業務建模時按照在同一聚合去建，落地時考慮現實，拆分聚合，通過 id 關聯。”
思考：
跟 “持有倉儲法” 很像，區別可能是在於代碼寫在哪裏，但是這種方法總感覺不是 OOP。
聚合拆分法
（我覺得 applicationService 中應該是跨領域的流程編排，Order，OrderItem 有相同的生命週期不能算跨領域，只能算誇聚合。至於 domainService，做爲領域的一部分，理論上不應該涉及基礎服務，只是存放業務相關但是不適合放在聚合中，也非跨域的代碼）
大佬建議：
“如果 OrderItem 超過 10 萬，20 萬， 這種情況一般大概率不需要一次性加載出來所有 OrderItem，而是分頁加載 OrderItem， 這和聚合的特點衝突，建議設計成兩個領域對象單獨管理”
思路：
建立 OrderAggregate 跟 OrderItemAggregate 兩個聚合，通過領域事件 實現最終一致。
靈活場景法 (聚合拆分法 Plus）
（感覺還是反模型，代碼好理解，業務專家不一定認可，不像自然語言那樣自然，爲了性能做出妥協）
如 demo 中我們要修改 OrderItem 的數量，這樣一個場景，場景主體是 OrderItem 而不是 Order，Order 被修改可以認爲是副作用。
明確場景的情況下 (明確上下文) 可以建模爲 OrderItemAggregate 和 OrderEntity 將 1:n 的關係轉化爲 1:1。
//訂單明細聚合
public class OrderItemAggregate {
//id
private Long id;
//商品(值對象)
private Product product;
//數量(值對象)
private Count count;
// item總價(值對象)
private ItemAmount itemAmt;
//Order實體
private OrderEntity orderEntity;
public void modifyCount(Count count) {
this.count = count;
ItemAmt itemAmt = new ItemAmt(this.product.getPrice()*this.count.get());
//order總價
Amt amt = this.orderEntity.getAmt();
//總價-item總價+新item總價
amt = new Amt(amt.get() - this.ItemAmt.get() + itemAmt.get());
//變更訂單總價
this.orderEntity.modifyAmt(amt);
this.itemAmt = itemAmt;
}
}
//訂單實體
public class OrderEntity {
//聚合唯一標識
private Long id;
//訂單號(值對象)
private OrderNo orderNo;
//總價 (值對象)
private Amount amt;
public Amount modifyAmt(Amt amt) {
//修改訂單總價
this.amt = amt;
}
}
//要訂單明細中 名稱叫電腦的商品數量修改100
orderItemAggregate.modifyCount(count);刪除 / 添加訂單明細同理。
而，訂單支付 (訂單被支付) 的場景，業務主體是 Order（這個場景下 OrderItem 甚至不會出現修改，當然也就沒有必要加載 OrderItem）。
總結
感謝各位大佬提供自己的思路爲我解惑。
對與聚合落地，因爲最後一種靈活場景變化聚合的思路，完全無關於基礎服務，保持了聚合內的一致性，符合 DDD 領域只關注業務的思想，而且勉強符合 OOP，且落地成本低，從心裏上我更傾向於最後一種方式。唯一的難點在於說服自己他是一個正常的業務模型。
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/7SRfVWckqDSPqAgA6PIY1A