UML：聚合關係：成員對象是整體的一部分，但是成員對象可以脫離整體對象獨立存在。如汽車（Car）與引擎（Engine）、輪胎（Wheel）、車燈（Light）之間的關係為聚合關係，引擎、輪胎、車燈可以脫離車而存在，比如把一個引擎換到另一個汽車上也可以。 組合關係：也表示的是一種整體和部分的關係，但是 ...
UML：
聚合關係：成員對象是整體的一部分，但是成員對象可以脫離整體對象獨立存在。
如汽車（Car）與引擎（Engine）、輪胎（Wheel）、車燈（Light）之間的關係為聚合關係，引擎、輪胎、車燈可以脫離車而存在，比如把一個引擎換到另一個汽車上也可以。
組合關係：也表示的是一種整體和部分的關係，但是在組合關係中整體對象可以控製成員對象的生命周期，一旦整體對象不存在，成員對象也不存在。
所以，UML中聚合與組合的共同點：是兩者都是整體與部分的關係，差別點：是整體消亡後，成員對象是否可以脫離整體對象而單獨存在。
DDD聚合
也是一種整體和部分的關係，部分脫離整體會變得毫無意義，整體和部分之間強調一致的生命周期，也就是整體消亡的話部分也一起消亡，不能單獨存在。所以，從定義來看DDD中的聚合應該和UML中的組合關係是同一種關係。所以，Martin Flower也說，DDD中的聚合是限定在DDD這個方法論的上下文中，它不同於其他上下文（UML）中的聚合。
一個例子
按照上面的定義，我們再來分析一下一個典型的例子，就是公司和部門的關係。
UML的角度：
1、一個公司由多個部門組成，所以滿足整體和部分的關係；
2、一個部門不能脫離公司和加入到其他公司；
所以，我們推導出，在UML中公司和部門應該屬於組合關係。
DDD的角度：
雖然基於UML的角度，公司和部門屬於組合關係，那在DDD中是否應該把部門聚合在公司下麵呢？我的看法是，雖然從生命周期上，確實部門不能脫離公司。但是DDD的聚合設計要考慮的因素會更加豐滿，比如：
- DDD強調需求和Bounded Context，也就是會基於需求和上下文進行建模，我們建模前必須要先確定當前的需求和上下文是什麼；
- 整體在當前上下文是否強關心部分的存在；
- 整體和部分之間是否存在某些不變性規則；
- 操作整體與操作部分的業務場景是否一致；
- 性能問題，如果整體聚合的部分的數量過大，那也不會考慮聚合，即小聚合原則；
- 一致性問題，我們在設計系統時，即便把本該是聚合在一起的對象分開設計為多個聚合，也可以從技術上去解決一致性，比如通過領域服務來完成多個聚合的協同創建、刪除、修改，並能通過資料庫事務來保證嚴格的強一致性；
- DDD領域建模會對領域概念進行抽象，所以再領域模型中，在有些業務系統如組織架構管理系統中，也許就沒有公司了，而是只有部門，把公司也看成是一個頂層的部門就行，所以自然就不會有公司這個聚合根了；
所以，在進行DDD聚合設計時，如果僅從整體消亡後部分是否仍然存在意義這個點去推導的話，那考慮的就太單薄了，很有可能會得出不合理的聚合設計，最終很可能會導致聚合設計過大。這是沒有認真分析業務需求，沒有分析業務規則不變性，沒有對領域概念進行合理抽象，沒有進行OO軟體設計原則的應用的表現。
所以，以上案例由於需求不明，無法進行聚合設計。
題外話
我覺得DDD是對OOA/D的一個衍生，OOA/D是一種面向對象分析與設計的思想，強調通過設計對象，為對象分配職責，並讓對象之間通過協作的方式來完成軟體功能。而DDD則是對OO中的對象進行進一步的細化，比如首次提出了聚合、聚合根、實體、值對象、工廠、領域服務、領域事件，等。尤其是聚合的提出，讓OO設計更加豐富，大大減少了對象之間的關係複雜度，以及對象之間邊界的更加清晰。但是聚合的設計也很有難度，比如技術人員需要從我上面列舉的這些角度（不限於此）去進行聚合分析設計，這對開發人員的能力素質是一個很大的要求，可以說如果不會OOA/D的分析思維，就很難進行DDD領域建模。所以，我想這也是DDD很難在業務系統中落地的一個很大的原因之一吧。
