DDD中的聚合和UML中的聚合以及組合的關係

UML：

聚合關係：成員對象是總體的一部分，可是成員對象能夠脫離總體對象獨立存在。
如汽車（Car）與引擎（Engine）、輪胎（Wheel）、車燈（Light）之間的關係爲聚合關係，引擎、輪胎、車燈能夠脫離車而存在，好比把一個引擎換到另外一個汽車上也能夠。

組合關係：也表示的是一種總體和部分的關係，可是在組合關係中總體對象能夠控制成員對象的生命週期，一旦總體對象不存在，成員對象也不存在。

因此，UML中聚合與組合的共同點：是二者都是總體與部分的關係，差異點：是總體消亡後，成員對象是否能夠脫離總體對象而單獨存在。

DDD聚合

也是一種總體和部分的關係，部分脫離總體會變得毫無心義，總體和部分之間強調一致的生命週期，也就是總體消亡的話部分也一塊兒消亡，不能單獨存在。因此，從定義來看DDD中的聚合應該和UML中的組合關係是同一種關係。因此，Martin Flower也說，DDD中的聚合是限定在DDD這個方法論的上下文中，它不一樣於其餘上下文（UML）中的聚合。

一個例子

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

UML的角度：
一、一個公司由多個部門組成，因此知足總體和部分的關係；
二、一個部門不能脫離公司和加入到其餘公司；

因此，咱們推導出，在UML中公司和部門應該屬於組合關係。

DDD的角度：
雖然基於UML的角度，公司和部門屬於組合關係，那在DDD中是否應該把部門聚合在公司下面呢？個人見解是，雖然從生命週期上，確實部門不能脫離公司。可是DDD的聚合設計要考慮的因素會更加豐滿，好比：

• DDD強調需求和Bounded Context，也就是會基於需求和上下文進行建模，咱們建模前必需要先肯定當前的需求和上下文是什麼；
• 總體在當前上下文是否強關心部分的存在；
• 總體和部分之間是否存在某些不變性規則；
• 操做總體與操做部分的業務場景是否一致；
• 性能問題，若是總體聚合的部分的數量過大，那也不會考慮聚合，即小聚合原則；
• 一致性問題，咱們在設計系統時，即使把本該是聚合在一塊兒的對象分開設計爲多個聚合，也能夠從技術上去解決一致性，好比經過領域服務來完成多個聚合的協同建立、刪除、修改，並能經過數據庫事務來保證嚴格的強一致性；
• DDD領域建模會對領域概念進行抽象，因此再領域模型中，在有些業務系統如組織架構管理系統中，也許就沒有公司了，而是隻有部門，把公司也當作是一個頂層的部門就行，因此天然就不會有公司這個聚合根了；

因此，在進行DDD聚合設計時，若是僅從總體消亡後部分是否仍然存在乎義這個點去推導的話，那考慮的就太單薄了，頗有可能會得出不合理的聚合設計，最終極可能會致使聚合設計過大。這是沒有認真分析業務需求，沒有分析業務規則不變性，沒有對領域概念進行合理抽象，沒有進行OO軟件設計原則的應用的表現。

因此，以上案例因爲需求不明，沒法進行聚合設計。

題外話

我以爲DDD是對OOA/D的一個衍生，OOA/D是一種面向對象分析與設計的思想，強調經過設計對象，爲對象分配職責，並讓對象之間經過協做的方式來完成軟件功能。而DDD則是對OO中的對象進行進一步的細化，好比首次提出了聚合、聚合根、實體、值對象、工廠、領域服務、領域事件，等。尤爲是聚合的提出，讓OO設計更加豐富，大大減小了對象之間的關係複雜度，以及對象之間邊界的更加清晰。可是聚合的設計也頗有難度，好比技術人員須要從我上面列舉的這些角度（不限於此）去進行聚合分析設計，這對開發人員的能力素質是一個很大的要求，能夠說若是不會OOA/D的分析思惟，就很難進行DDD領域建模。因此，我想這也是DDD很難在業務系統中落地的一個很大的緣由之一吧。