uml：
聚合關係：成員物件是整體的一部分，但是成員物件可以脫離整體物件獨立存在。
如汽車（car）與引擎（engine）、輪胎（wheel）、車燈（light）之間的關係為聚合關係，引擎、輪胎、車燈可以脫離車而存在，比如把乙個引擎換到另乙個汽車上也可以。
組合關係：也表示的是一種整體和部分的關係，但是在組合關係中整體物件可以控制成員物件的生命週期，一旦整體物件不存在，成員物件也不存在，整體物件和成員物件之間具有同生共死的關係。
所以，聚合和組合的差別就一點：整體和部分的生命週期是否一致，即整體消亡後，成員物件是否可以脫離整體物件而單獨存在。
ddd聚合關係：
也是一種整體和部分的關係，部分脫離整體會變得毫無意義，強調同生共死的一致的生命週期。所以，從定義來看ddd中的聚合應該和uml中的組合關係是一致的。
按照上面的定義，我們在來分析一下乙個典型的例子，就是公司和部門的關係。
uml的角度：
1、乙個公司由多個部門組成，所以滿足整體和部分的關係；
2、乙個部門不能脫離公司和加入到其他公司；
所以，在uml中應該屬於組合關係，沒有問題。
ddd的角度：
雖然基於uml的角度，公司和部門屬於組合關係，那在ddd中是否應該把部門聚合在公司下面呢？我的看法是，雖然從生命週期上，確實部門不能脫離公司。
但是ddd的聚合設計要考慮的因素會更加豐滿，比如：
所以，在進行ddd聚合設計時，如果僅從整體刪除後部分會變得毫無意義(即物件之間的生命週期)這個點去推導的話，那考慮的就太單薄了，很有可能會得出不合理的聚合設計。
這是沒有認真分析業務需求，沒有分析業務規則不變性，沒有對領域概念進行合理抽象，沒有進行oo軟體設計原則的應用的表現。
我想，這也是為什麼ddd聚合設計為何會如此之難的原因了。
所以，結論是，以上案例由於需求不明，無法進行聚合設計，大家是不是很意外呢？居然沒有給出答案:)
UML中聚合和組合的區別
聚合 聚合其實是關聯的乙個特例，表示了兩個物件之間 part of 部分 整體 的關係，是一種弱關聯，部分的生命週期可以超越整體。在uml中，用整體端有空心菱形箭頭的雙向關聯修飾聚合。聚合的示例如下圖 組合 組合其實是一種強形式的聚合，它具有強的擁有關係，整體與部分的生命週期是一致的。部分 生存在整...
UML中聚合和組合的區別
一直以來，對uml的東西總是模稜兩可，對於類圖中的聚合和組合，知道兩種的區別，但過一段時間後總是分不清兩者誰是誰，唉，主要怪自己的語文沒有學好，呵呵！其實，對於聚合和組合，如果換成英文，就很好理解了 聚合就是 has a 組合就是 contains a 聚合是空心的菱形 組合是實心的菱形 這個比較好...
危險的DDD聚合根
原文 危險的ddd聚合根 ddd的核心是聚合。這沒有問題，大家都認同。但關於ddd中的聚合方式，其實我還是有些擔心，下面說說我的想法，希望大家參與討論。其實當初第一次看到ddd中關於聚合根部分論述的時候，就感覺有些僵化。ddd中的聚合根的分析設計思路大致是這樣 1 業務本質邏輯分析 2 確認聚合物件...