DDD(五)--集合、聚合根

---

一、引言

聚合，字面意思就很簡潔明瞭，是把領域對象聚合在一塊兒，並維護領域對象之間的關係。

聚合其實就是一個在不改變原有實體的狀況下將若干實體彙集起來。

---

二、爲何要聚合呢

在開發中不少實體有着多個一對一，一對多的關聯，聚合是爲了儘量減小這些關聯，用作解耦合，也同時能夠清晰的反應業務。

同時行外人士對系統的認知也是聚合，使用者不會考慮是用戶仍是訂單，若是訂單消失，那麼保存這個訂單的信息所在的意義微乎其微。

舉個例子，實體用戶、訂單、商品組成一個聚合，這個聚合是爲了表達用戶與訂單的關係的，用戶購買商品生成訂單，放在一個聚合內，訂單是這個聚合根，訂單中保存着用戶id和商品id。可代入上圖理解。

---

三、聚合的特性

上述例子是聚合嗎？實際上是存在問題的，若是商品漲價了，商品下架了，商品更名了用戶看起來豈不是很迷惑？因此並非隨便幾個實體就能組成聚合的，聚合要保證不變性和一致性，不變性個人理解是不會輕易改變，若是是聚合根本身改變的那固然是能夠的，因此要保證一致性，在這個聚合內，不管怎麼改變，必須是強一致的。

我認爲聚合在代碼內部的體現其實也是一個實體，甚至能夠表明一個領域，但這不是說聚合是領域，準確來講領域能夠是聚合，可是聚合不必定是領域。爲何聚合不必定是領域呢？若是有太多太多的實體組成一個聚合，那麼這個聚合爲了保證一致性和不變性是很是困難的，因此聚合要儘量的設計的小。

聚合既能夠表達一個領域，同時也能夠表達邊界，限制邊界。

---

四、小結

現現在微服務普遍運用，因此我有一個疑問，在微服務架構中如何聚合。在網上看到這麼一個例子用戶購買電影票，須要同時訪問用戶微服務和電影微服務。若是讓用戶直接發請求給各個服務，那其中效率無疑是很低下的。可是能夠用一種聚合微服務技術，手機發送請求給聚合微服務，聚合微服務再給電影和用戶微服務發請求，再將電影票信息響應給用戶。由於聚合微服務、電影微服務、用戶微服務通常會在一個局域網內，因此效率會很高，不須要用戶發送兩個請求。

其實這就很好的解釋了DDD中聚合這一律念。聚合的緣由其一是爲了提升效率，其次也能明確的表達某一業務。聚合在DDD中是很是重要的，由於DDD自己的思想就是針對業務，針對領域，這對使用和理解DDD都很方便。