UML：
聚合關系：成員對象是整體的一部分，但是成員對象可以脫離整體對象獨立存在。
如汽車（Car）與引擎（Engine）、輪胎（Wheel）、車燈（Light）之間的關系為聚合關系，引擎、輪胎、車燈可以脫離車而存在，比如把一個引擎換到另一個汽車上也可以。

組合關系：也表示的是一種整體和部分的關系，但是在組合關系中整體對象可以控制成員對象的生命周期，一旦整體對象不存在，成員對象也不存在，整體對象和成員對象之間具有同生共死的關系。

所以，聚合和組合的差別就一點：整體和部分的生命周期是否一致，即整體消亡后，成員對象是否可以脫離整體對象而單獨存在。

DDD聚合關系：
也是一種整體和部分的關系，部分脫離整體會變得毫無意義，強調同生共死的一致的生命周期。所以，從定義來看DDD中的聚合應該和UML中的組合關系是一致的。

按照上面的定義，我們在來分析一下一個典型的例子，就是公司和部門的關系。

UML的角度：
1、一個公司由多個部門組成，所以滿足整體和部分的關系；
2、一個部門不能脫離公司和加入到其他公司；

所以，在UML中應該屬于組合關系，沒有問題。

DDD的角度：
雖然基于UML的角度，公司和部門屬于組合關系，那在DDD中是否應該把部門聚合在公司下面呢？我的看法是，雖然從生命周期上，確實部門不能脫離公司。
但是DDD的聚合設計要考慮的因素會更加豐滿，比如：

• DDD強調需求和Bounded Context，也就是會基于需求和上下文進行建模，我們建模前必須要先確定當前的需求和上下文是什么；

• 整體在當前上下文是否強關心部分的存在；

• 整體和部分之間是否存在某些不變性規則；

• 操作整體與操作部分的業務場景是否一致；

• 性能問題，如果整體聚合的部分數量過大，那也不會考慮聚合，即小聚合原則；

• 一致性問題，我們在設計系統時，即便把本該是聚合在一起的對象分開設計為多個聚合，也可以從技術上去解決一致性，比如通過領域服務來完成多個聚合的協同創建、刪除、修改，并能通過數據庫事務來保證嚴格的強一致性；

• DDD領域建模會對領域概念進行抽象，所以再領域模型中，也許就沒有公司了，而是只有部門，把公司也看成是一個頂層的部門就行，所以自然就不會有公司這個聚合根了；

所以，在進行DDD聚合設計時，如果僅從整體刪除后部分會變得毫無意義(即對象之間的生命周期)這個點去推導的話，那考慮的就太單薄了，很有可能會得出不合理的聚合設計。
這是沒有認真分析業務需求，沒有分析業務規則不變性，沒有對領域概念進行合理抽象，沒有進行OO軟件設計原則的應用的表現。

我想，這也是為什么DDD聚合設計為何會如此之難的原因了。

所以，結論是，以上案例由于需求不明，無法進行聚合設計，大家是不是很意外呢？居然沒有給出答案:)

原文地址：https://www.cnblogs.com/netfocus/p/11078464.html

總結

以上是生活随笔為你收集整理的DDD中的聚合和UML中的聚合以及组合的关系的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。