淺談DDD中的聚合_ZenDei技術網路在線

在我看來並不是MVC的基礎上增加領域層，使用充血模型，解耦基礎服務，我的代碼就符合DDD了。為什麼要使用DDD? DDD分為戰略部分跟戰術部分，相信大家都認同DDD的核心在戰略而非戰術。而戰略方面的核心我認為在業務建模，領域劃分、統一語言等都在為業務建模服務。為什麼業務建模重要? ... ...

在我看來並不是MVC的基礎上增加領域層，使用充血模型，解耦基礎服務，我的代碼就符合DDD了。

為什麼要使用DDD?

DDD分為戰略部分跟戰術部分，相信大家都認同DDD的核心在戰略而非戰術。而戰略方面的核心我認為在業務建模，領域劃分、統一語言等都在為業務建模服務。

為什麼業務建模重要?

以前的開發流程有什麼問題？

先說結論，開發人員交付的程式對業務方，產品人員，測試人員來說就是一個黑盒子。除了開發人員自己，沒人知道盒子里有什麼。當新的需求加入來，需求方，產品人員，甚至測試人員都認為可行，開發人員卻給出相反結論。

回顧一下以前的開發流程大致可以歸結為以下步驟：(開發跟測試人員最好能參與需求分析)

1.業務方描述抽象需求

2.產品將需求轉化為可落地的產品(需求具像化,PRD)

3.開發人員根據產品的PRD開發

4.測試人員根據產品的PRD測試

5.產品人員驗收

6.業務方驗收

依照經驗來說,在整個流程中開發人員是耗時最長的。與此同時測試人員可能在編寫測試用例，而業務方跟產品人員在這段時間內是阻塞的。最終的程式質量靠測試人員來保障。

開發人員完成開發後:

測試人員關註測試用例是否通過。

產品人員確認展現出來的功能是否符合當初的PRD。

業務方確認程式是否符合預期。

舉一個我開發項目的例子

一個審批系統

產品的PRD描述了一個三層模型：

流程實例,流程節點,審批任務。流程實例啟動創建審批節點，審批節點觸發審批任務，任務完成創建下一個節點...。

我是這樣做的：

流程實例,審批任務。流程實例啟動創建(一批)審批任務,任務被完成後創建後續任務或者流程結束。至於流程節點不存在，不是問題，從任務中提取信息虛擬一個出來。

第一版交付完成。

產品在第一版後追加需求

流程節點可以被非審批人評論。

我....

當時業務方，產品，測試都認為這是一個合理的需求。只有我一臉懵，因為我的程式中沒有流程節點這個東西，需求又不能拒絕，無奈給出一個遠超他們預期的開發計劃。

gap就出在他們認為流程節點是一個確實存在的東西，而只有我知道這節點是虛擬的，沒有標識，不能跟其他信息做關聯。

業務建模怎麼解決這個黑盒子問題?

DDD引入了業務專家這個角色(在我看來就是業務方，產品)。

1.假設業務專家聽不懂什麼叫類，什麼是方法，設計模式，他只知道他的業務，兩方人馬完全不在同一頻道，這個時候就需要“明確上下文”，“統一語言”了。(不僅僅開發人員與業務專家達成了共識，也包含整個開發團隊達成共識)

2.業務建模，用例分析法、事件風暴、四色建模等看看開始整上。最終達到劃分領域，識別聚合的目的。

3.業務建模落地。開發人員開發過程中，應遵守已經建立的業務模型來編寫代碼。

至此終於實現了，業務專家可通過業務模型窺探到開發人員的代碼實現。統一語言、業務模型在業務專家跟開發人員中間充當了溝通的橋梁。(有點像適配器)

當追加新的需求時，業務專家能合理評估需求的可行性。

讓非開發人員參與到開發中

統一語言，業務建模，模型充血（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>)，這裡就隱含了一個條件記憶體無限大。

假設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);