淺談軟件開發(fā)聚合的劃分與設(shè)計
聚合以及聚合根是領(lǐng)域驅(qū)動設(shè)計中的重要概念，根據(jù)定義，聚合是針對數(shù)據(jù)變化可以考慮成一個單元的一組相關(guān)的對象。聚合使用邊界將內(nèi)部和外部的對象劃分開來。每個聚合有一個根。這個根是一個實體，并且它是外部可以訪問的唯一的對象。根可以保持對任意聚合對象的引用，并且其他的對象可以持有任意其他的對象，但一個外部對象只能持有根對象的引用。如果邊界內(nèi)有其他的實體，那些實體的標(biāo)識符是本地化的，只在聚合內(nèi)有意義（參見《領(lǐng)域驅(qū)動設(shè)計-精簡版》第42頁）。從定義上看，貌似針對特定上下文的領(lǐng)域模型來講，聚合的劃分與設(shè)計并不那么困難，但事實卻并非如此。在本文中，我將大致總結(jié)一下自己的經(jīng)驗，同時也歡迎關(guān)注領(lǐng)域驅(qū)動設(shè)計的朋友能夠提出自己的見解。
幾周前我與園友netfocus討論過這個問題，在他的這篇博客中，簡單地提及了為何我們需要在領(lǐng)域驅(qū)動設(shè)計中引入“聚合”的概念。我們圍繞著《Effective Aggregate Design Part I: Modeling a Single Aggregate》一文中的一些觀點對聚合的劃分與設(shè)計展開討論，文中對聚合的設(shè)計問題作了討論，比如：如果將聚合設(shè)計得很大，則會帶來一些諸如一致性和事務(wù)失效（transaction failure）的問題；不僅如此，大聚合會導(dǎo)致系統(tǒng)性能低下，即使采用延遲加載（Lazy Loading）也無法徹底解決性能問題，例如當(dāng)更新某個聚合中實體集合中的某個實體時，會連同整個集合被同時加載到內(nèi)存中，而事實上這是不必要的。之后，文中提出將大聚合拆分成多個小聚合，通過引入領(lǐng)域服務(wù)（Domain Service），并使用實體標(biāo)識（Entity Identifier）來替代對象引用（reference）以避免大聚合帶來的并發(fā)問題，因此可以得出結(jié)論，就是聚合不能設(shè)計得很大結(jié)構(gòu)很復(fù)雜。然而應(yīng)該如何合理地去設(shè)計聚合、劃分聚合邊界呢？這就是本文所要討論的問題。
事實上，我對這篇文章的分析問題的方式不太認(rèn)同，雖然***的問題都?xì)w結(jié)到聚合的劃分與設(shè)計上。聚合的劃分與設(shè)計問題，我覺得不應(yīng)該從技術(shù)的角度去分析引出，而應(yīng)該從領(lǐng)域模型和通用語言的角度去概括，雖然文章中所闡述的問題都是現(xiàn)實存在的，但我覺得如果能夠從模型的角度來分析問題，或許能夠得到更好的結(jié)果。
聚合劃分與設(shè)計其實與并發(fā)和事務(wù)性并不矛盾
首先需要了解的是，合理地劃分和設(shè)計聚合，并不會產(chǎn)生任何并發(fā)和事務(wù)性問題。我們所討論的文章中之所以***個設(shè)計方案會出現(xiàn)并發(fā)和事務(wù)性問題，就是因為它的聚合設(shè)計本身就不合理。這其實在本文一開始就明確了這個問題：聚合是針對數(shù)據(jù)變化可以考慮成一個單元的一組相關(guān)的對象。因此，必須承認(rèn)對于一個聚合，其中包含的所有對象必須“同生死，共存亡”，基于聚合的數(shù)據(jù)操作應(yīng)該就是原子操作，基礎(chǔ)結(jié)構(gòu)機制需要保證以聚合為單位的數(shù)據(jù)一致性。換句話說，聚合在數(shù)據(jù)一致性方面的表現(xiàn)，應(yīng)該與基礎(chǔ)結(jié)構(gòu)機制所保證的并發(fā)和事務(wù)的正確性是等價的。數(shù)據(jù)訪問時出現(xiàn)的事務(wù)失效現(xiàn)象，其實是源于聚合的不合理劃分。比如，在《Effective Aggregate Design》一文中的例子里，事實上Product并不一定要依賴于Release才能存在，因此，在Product的聚合中，就不應(yīng)該包含對Release的引用，然而相反，Release是沒法脫離Product而單獨存在的，因為如果是這樣的話，Release也就失去了本身的含義，所以，Release可以定義成一個聚合，而Product則是這個聚合中的一個實體。
至此，我們可以得知，聚合的劃分和設(shè)計必須依賴對通用語言、領(lǐng)域概念和模型的正確把握。接下來再讓我們看兩個我們經(jīng)常遇到的例子：銷售訂單和論壇主題。
兩個例子：銷售訂單（Sales Order）/訂單明細(xì)（Sales Line） vs. 論壇主題（Post）/回復(fù)（Reply）
很多網(wǎng)友會在這兩個領(lǐng)域的建模上感到糾結(jié)，如果我們從數(shù)據(jù)庫設(shè)計上考慮（以數(shù)據(jù)庫驅(qū)動的開發(fā)方式進行思考），兩者非常相似，都是主從表結(jié)構(gòu)，都是1對多（1:N）的關(guān)系：一個銷售訂單對應(yīng)多條訂單明細(xì)，一個論壇主題對應(yīng)多條回復(fù)。但如果我們用領(lǐng)域驅(qū)動的思想來考慮這個問題，我們會發(fā)現(xiàn)，這是兩個截然不同的例子！兩個例子中實體之間的關(guān)系完全不同。
首先分析銷售訂單（Sales Order）/訂單明細(xì)（Sales Line）：對于一張銷售訂單來說，訂單明細(xì)是不可缺少的，否則就不成其為銷售訂單。試想，一張訂單沒有包含任何購買的貨品信息，這意味著什么？因此，銷售訂單和訂單明細(xì)之間的關(guān)系是一種固定的不可變（invariant）的關(guān)系，就像《領(lǐng)域驅(qū)動設(shè)計》一書中所講的汽車與車輪之間的關(guān)系那樣，汽車少了輪子就不成其為汽車了。反過來看，訂單明細(xì)也離不開銷售訂單，這很簡單，因為很明細(xì)訂單明細(xì)是描述銷售訂單的一個不可或缺的部分。于是，在這個例子中，我們有一個聚合根為銷售訂單，其中包含一條或多條訂單明細(xì)的聚合，聚合及其實體間的關(guān)系可以用下圖表示：
對于論壇主題（Post）/回復(fù)（Reply）之間的關(guān)系，情況卻完全不同。論壇的主題是可以脫離回復(fù)單獨存在的（一個主題可以沒有任何人對其進行回復(fù)），而回復(fù)卻不能脫離主題（沒有主題的回復(fù)是沒有意義的）。鑒于這樣的事實，實際上在主題與回復(fù)這部分模型中，存在兩個聚合：***個聚合是以主題（Post）為聚合根，且僅包含其本身一個對象的聚合；另一個聚合是以回復(fù)（Reply）為聚合根，其中包含了對主題（Post）的引用的聚合。其關(guān)系可以如下表示：
這樣的設(shè)計，會讓有些朋友感到不適應(yīng)，原因是我們無法直接從Post實體獲得其下所有的Reply實體，那么對于“通過給定的Post，獲得與它相關(guān)的所有Reply信息”這樣的用例，在實現(xiàn)上就不那么直接。此時，我們需要在應(yīng)用層，通過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;
- }
- }
這部分內(nèi)容牽涉到了應(yīng)用層，或許你會覺得，這樣做是不是把業(yè)務(wù)邏輯遷移到了應(yīng)用層，導(dǎo)致領(lǐng)域模型失血。其實不然，在這里，應(yīng)用層并沒有參與任何業(yè)務(wù)邏輯，從倉儲讀取領(lǐng)域?qū)ο笠约皩㈩I(lǐng)域?qū)ο筠D(zhuǎn)換成數(shù)據(jù)傳輸對象（DTO），這些并不屬于業(yè)務(wù)邏輯的范疇：因為從領(lǐng)域模型和業(yè)務(wù)邏輯的角度看，它們并不能知道什么是倉儲、什么是規(guī)約、什么是數(shù)據(jù)傳輸對象。應(yīng)用層在這里起到了任務(wù)協(xié)調(diào)、數(shù)據(jù)轉(zhuǎn)換等作用。不僅如此，應(yīng)用層甚至還可以包含業(yè)務(wù)規(guī)則引擎以及工作流的實現(xiàn)（workflow）。這部分內(nèi)容我將在后續(xù)的博文中介紹。
本文簡要介紹了一些有關(guān)聚合設(shè)計與劃分的思想，有興趣的朋友可以繼續(xù)進行深入思考，也歡迎大家提出各自的見解與想法，一起討論。
原文鏈接：http://www.cnblogs.com/daxnet/archive/2011/12/24/2300169.html
【編輯推薦】
