聚合以及聚合根是領域驅動設計中的重要概念，根據定義，聚合是針對數據變化可以考慮成一個單元的一組相關的對象。聚合使用邊界將內部和外部的對象划分開來。每個聚合有一個根。這個根是一個實體，並且它是外部可以訪問的唯一的對象。根可以保持對任意聚合對象的引用，並且其他的對象可以持有任意其他的對象，但一個外部對象只能持有根對象的引用。如果邊界內有其他的實體，那些實體的標識符是本地化的，只在聚合內有意義（參見《領域驅動設計-精簡版》第42頁）。從定義上看，貌似針對特定上下文的領域模型來講，聚合的划分與設計並不那么困難，但事實卻並非如此。在本文中，我將大致總結一下自己的經驗，同時也歡迎關注領域驅動設計的朋友能夠提出自己的見解。
幾周前我與園友netfocus討論過這個問題，在他的這篇博客中，簡單地提及了為何我們需要在領域驅動設計中引入“聚合”的概念。我們圍繞着《Effective Aggregate Design Part I: Modeling a Single Aggregate》一文中的一些觀點對聚合的划分與設計展開討論，文中對聚合的設計問題作了討論，比如：如果將聚合設計得很大，則會帶來一些諸如一致性和事務失效（transaction failure）的問題；不僅如此，大聚合會導致系統性能低下，即使采用延遲加載（Lazy Loading）也無法徹底解決性能問題，例如當更新某個聚合中實體集合中的某個實體時，會連同整個集合被同時加載到內存中，而事實上這是不必要的。之后，文中提出將大聚合拆分成多個小聚合，通過引入領域服務（Domain Service），並使用實體標識（Entity Identifier）來替代對象引用（reference）以避免大聚合帶來的並發問題，因此可以得出結論，就是聚合不能設計得很大結構很復雜。然而應該如何合理地去設計聚合、划分聚合邊界呢？這就是本文所要討論的問題。
事實上，我對這篇文章的分析問題的方式不太認同，雖然最后的問題都歸結到聚合的划分與設計上。聚合的划分與設計問題，我覺得不應該從技術的角度去分析引出，而應該從領域模型和通用語言的角度去概括，雖然文章中所闡述的問題都是現實存在的，但我覺得如果能夠從模型的角度來分析問題，或許能夠得到更好的結果。
聚合划分與設計其實與並發和事務性並不矛盾
首先需要了解的是，合理地划分和設計聚合，並不會產生任何並發和事務性問題。我們所討論的文章中之所以第一個設計方案會出現並發和事務性問題，就是因為它的聚合設計本身就不合理。這其實在本文一開始就明確了這個問題：聚合是針對數據變化可以考慮成一個單元的一組相關的對象。因此，必須承認對於一個聚合，其中包含的所有對象必須“同生死，共存亡”，基於聚合的數據操作應該就是原子操作，基礎結構機制需要保證以聚合為單位的數據一致性。換句話說，聚合在數據一致性方面的表現，應該與基礎結構機制所保證的並發和事務的正確性是等價的。數據訪問時出現的事務失效現象，其實是源於聚合的不合理划分。比如，在《Effective Aggregate Design》一文中的例子里，事實上Product並不一定要依賴於Release才能存在，因此，在Product的聚合中，就不應該包含對Release的引用，然而相反，Release是沒法脫離Product而單獨存在的，因為如果是這樣的話，Release也就失去了本身的含義，所以，Release可以定義成一個聚合，而Product則是這個聚合中的一個實體。
至此，我們可以得知，聚合的划分和設計必須依賴對通用語言、領域概念和模型的正確把握。接下來再讓我們看兩個我們經常遇到的例子：銷售訂單和論壇主題。
兩個例子：銷售訂單（Sales Order）/訂單明細（Sales Line） vs. 論壇主題（Post）/回復（Reply）
很多網友會在這兩個領域的建模上感到糾結，如果我們從數據庫設計上考慮（以數據庫驅動的開發方式進行思考），兩者非常相似，都是主從表結構，都是1對多（1:N）的關系：一個銷售訂單對應多條訂單明細，一個論壇主題對應多條回復。但如果我們用領域驅動的思想來考慮這個問題，我們會發現，這是兩個截然不同的例子！兩個例子中實體之間的關系完全不同。
首先分析銷售訂單（Sales Order）/訂單明細（Sales Line）：對於一張銷售訂單來說，訂單明細是不可缺少的，否則就不成其為銷售訂單。試想，一張訂單沒有包含任何購買的貨品信息，這意味着什么？因此，銷售訂單和訂單明細之間的關系是一種固定的不可變（invariant）的關系，就像《領域驅動設計》一書中所講的汽車與車輪之間的關系那樣，汽車少了輪子就不成其為汽車了。反過來看，訂單明細也離不開銷售訂單，這很簡單，因為很明細訂單明細是描述銷售訂單的一個不可或缺的部分。於是，在這個例子中，我們有一個聚合根為銷售訂單，其中包含一條或多條訂單明細的聚合，聚合及其實體間的關系可以用下圖表示：
對於論壇主題（Post）/回復（Reply）之間的關系，情況卻完全不同。論壇的主題是可以脫離回復單獨存在的（一個主題可以沒有任何人對其進行回復），而回復卻不能脫離主題（沒有主題的回復是沒有意義的）。鑒於這樣的事實，實際上在主題與回復這部分模型中，存在兩個聚合：第一個聚合是以主題（Post）為聚合根，且僅包含其本身一個對象的聚合；另一個聚合是以回復（Reply）為聚合根，其中包含了對主題（Post）的引用的聚合。其關系可以如下表示：
這樣的設計，會讓有些朋友感到不適應，原因是我們無法直接從Post實體獲得其下所有的Reply實體，那么對於“通過給定的Post，獲得與它相關的所有Reply信息”這樣的用例，在實現上就不那么直接。此時，我們需要在應用層，通過Reply的倉儲來獲得，比如：
public IEnumerable<ReplyDataObject> GetRepliesForPost(Guid postId)
{
using (IRepositoryContext context = IoCFactory.GetService<IRepositoryContext>();
{
ISpecification<Reply> spec = Specification<Reply>.Eval(r => r.Post.Id == postId);
IRepository<Reply> replyRepository = context.GetRepository<Reply>();
IEnumerable<Reply> replies = replyRepository.FindAll(spec);
List<ReplyDataObject> result = new List<ReplyDataObject>();
if (replies != null)
{
replies.ToList().ForEach(r => result.Add(DataObjectMapper.MapToDataObject(r));
}
return result;
}
}
這部分內容牽涉到了應用層，或許你會覺得，這樣做是不是把業務邏輯遷移到了應用層，導致領域模型失血。其實不然，在這里，應用層並沒有參與任何業務邏輯，從倉儲讀取領域對象以及將領域對象轉換成數據傳輸對象（DTO），這些並不屬於業務邏輯的范疇：因為從領域模型和業務邏輯的角度看，它們並不能知道什么是倉儲、什么是規約、什么是數據傳輸對象。應用層在這里起到了任務協調、數據轉換等作用。不僅如此，應用層甚至還可以包含業務規則引擎以及工作流的實現（workflow）。這部分內容我將在后續的博文中介紹。
本文簡要介紹了一些有關聚合設計與划分的思想，有興趣的朋友可以繼續進行深入思考，也歡迎大家提出各自的見解與想法，一起討論。