淺談軟件開發聚合的劃分與設計
聚合以及聚合根是領域驅動設計中的重要概念，根據定義，聚合是針對數據變化可以考慮成一個單元的一組相關的對象。聚合使用邊界將內部和外部的對象劃分開來。每個聚合有一個根。這個根是一個實體，并且它是外部可以訪問的唯一的對象。根可以保持對任意聚合對象的引用，并且其他的對象可以持有任意其他的對象，但一個外部對象只能持有根對象的引用。如果邊界內有其他的實體，那些實體的標識符是本地化的，只在聚合內有意義（參見《領域驅動設計-精簡版》第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）。這部分內容我將在后續的博文中介紹。
本文簡要介紹了一些有關聚合設計與劃分的思想，有興趣的朋友可以繼續進行深入思考，也歡迎大家提出各自的見解與想法，一起討論。
原文鏈接：http://www.cnblogs.com/daxnet/archive/2011/12/24/2300169.html
【編輯推薦】
