學(xué)習(xí)完整課程請(qǐng)移步 互聯(lián)網(wǎng) Java 全棧工程師

【領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)】淺談聚合的劃分與設(shè)計(jì)

聚合以及聚合根是領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)中的重要概念掂骏，根據(jù)定義靖诗，聚合是針對(duì)數(shù)據(jù)變化可以考慮成一個(gè)單元的一組相關(guān)的對(duì)象芍瑞。聚合使用邊界將內(nèi)部和外部的對(duì)象劃分開(kāi)來(lái)课竣。每個(gè)聚合有一個(gè)根朦促。這個(gè)根是一個(gè)實(shí)體童太，并且它是外部可以訪問(wèn)的唯一的對(duì)象米辐。根可以保持對(duì)任意聚合對(duì)象的引用，并且其他的對(duì)象可以持有任意其他的對(duì)象书释，但一個(gè)外部對(duì)象只能持有根對(duì)象的引用翘贮。如果邊界內(nèi)有其他的實(shí)體，那些實(shí)體的標(biāo)識(shí)符是本地化的爆惧，只在聚合內(nèi)有意義（參見(jiàn)《領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)-精簡(jiǎn)版》第42頁(yè)）狸页。從定義上看，貌似針對(duì)特定上下文的領(lǐng)域模型來(lái)講扯再，聚合的劃分與設(shè)計(jì)并不那么困難芍耘，但事實(shí)卻并非如此。在本文中熄阻，我將大致總結(jié)一下自己的經(jīng)驗(yàn)斋竞，同時(shí)也歡迎關(guān)注領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的朋友能夠提出自己的見(jiàn)解。

聚合劃分與設(shè)計(jì)其實(shí)與并發(fā)和事務(wù)性并不矛盾

首先需要了解的是秃殉，合理地劃分和設(shè)計(jì)聚合坝初，并不會(huì)產(chǎn)生任何并發(fā)和事務(wù)性問(wèn)題浸剩。我們所討論的文章中之所以第一個(gè)設(shè)計(jì)方案會(huì)出現(xiàn)并發(fā)和事務(wù)性問(wèn)題，就是因?yàn)樗木酆显O(shè)計(jì)本身就不合理脖卖。這其實(shí)在本文一開(kāi)始就明確了這個(gè)問(wèn)題：聚合是針對(duì)數(shù)據(jù)變化可以考慮成一個(gè)單元的一組相關(guān)的對(duì)象乒省。因此，必須承認(rèn)對(duì)于一個(gè)聚合畦木，其中包含的所有對(duì)象必須“同生死，共存亡”砸泛，基于聚合的數(shù)據(jù)操作應(yīng)該就是原子操作十籍，基礎(chǔ)結(jié)構(gòu)機(jī)制需要保證以聚合為單位的數(shù)據(jù)一致性。換句話說(shuō)唇礁，聚合在數(shù)據(jù)一致性方面的表現(xiàn)勾栗，應(yīng)該與基礎(chǔ)結(jié)構(gòu)機(jī)制所保證的并發(fā)和事務(wù)的正確性是等價(jià)的。數(shù)據(jù)訪問(wèn)時(shí)出現(xiàn)的事務(wù)失效現(xiàn)象盏筐，其實(shí)是源于聚合的不合理劃分围俘。比如，在《Effective Aggregate Design》一文中的例子里琢融，事實(shí)上 Product 并不一定要依賴于 Release 才能存在界牡，因此，在 Product 的聚合中漾抬，就不應(yīng)該包含對(duì) Release 的引用宿亡，然而相反，Release 是沒(méi)法脫離 Product 而單獨(dú)存在的纳令，因?yàn)槿绻沁@樣的話挽荠，Release 也就失去了本身的含義，所以平绩，Release 可以定義成一個(gè)聚合圈匆，而 Product 則是這個(gè)聚合中的一個(gè)實(shí)體。

至此捏雌，我們可以得知跃赚，聚合的劃分和設(shè)計(jì)必須依賴對(duì)通用語(yǔ)言、領(lǐng)域概念和模型的正確把握腹忽。接下來(lái)再讓我們看兩個(gè)我們經(jīng)常遇到的例子：銷售訂單和論壇主題来累。

兩個(gè)例子：銷售訂單（Sales Order）/訂單明細(xì)（Sales Line） vs. 論壇主題（Post）/回復(fù)（Reply）

很多網(wǎng)友會(huì)在這兩個(gè)領(lǐng)域的建模上感到糾結(jié)，如果我們從數(shù)據(jù)庫(kù)設(shè)計(jì)上考慮（以數(shù)據(jù)庫(kù)驅(qū)動(dòng)的開(kāi)發(fā)方式進(jìn)行思考）窘奏，兩者非常相似嘹锁，都是主從表結(jié)構(gòu)，都是1對(duì)多（1:N）的關(guān)系：一個(gè)銷售訂單對(duì)應(yīng)多條訂單明細(xì)着裹，一個(gè)論壇主題對(duì)應(yīng)多條回復(fù)领猾。但如果我們用領(lǐng)域驅(qū)動(dòng)的思想來(lái)考慮這個(gè)問(wèn)題，我們會(huì)發(fā)現(xiàn)，這是兩個(gè)截然不同的例子摔竿！兩個(gè)例子中實(shí)體之間的關(guān)系完全不同面粮。

首先分析銷售訂單（Sales Order）/訂單明細(xì)（Sales Line）：對(duì)于一張銷售訂單來(lái)說(shuō)，訂單明細(xì)是不可缺少的继低，否則就不成其為銷售訂單熬苍。試想，一張訂單沒(méi)有包含任何購(gòu)買的貨品信息袁翁，這意味著什么柴底？因此，銷售訂單和訂單明細(xì)之間的關(guān)系是一種固定的不可變（invariant）的關(guān)系粱胜，就像《領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)》一書(shū)中所講的汽車與車輪之間的關(guān)系那樣柄驻，汽車少了輪子就不成其為汽車了。反過(guò)來(lái)看焙压，訂單明細(xì)也離不開(kāi)銷售訂單鸿脓，這很簡(jiǎn)單，因?yàn)楹苊骷?xì)訂單明細(xì)是描述銷售訂單的一個(gè)不可或缺的部分涯曲。于是野哭，在這個(gè)例子中，我們有一個(gè)聚合根為銷售訂單掀抹，其中包含一條或多條訂單明細(xì)的聚合虐拓，聚合及其實(shí)體間的關(guān)系可以用下圖表示：

image

對(duì)于論壇主題（Post）/回復(fù)（Reply）之間的關(guān)系，情況卻完全不同傲武。論壇的主題是可以脫離回復(fù)單獨(dú)存在的（一個(gè)主題可以沒(méi)有任何人對(duì)其進(jìn)行回復(fù)）蓉驹，而回復(fù)卻不能脫離主題（沒(méi)有主題的回復(fù)是沒(méi)有意義的）。鑒于這樣的事實(shí)揪利，實(shí)際上在主題與回復(fù)這部分模型中态兴，存在兩個(gè)聚合：第一個(gè)聚合是以主題（Post）為聚合根，且僅包含其本身一個(gè)對(duì)象的聚合疟位；另一個(gè)聚合是以回復(fù)（Reply）為聚合根瞻润，其中包含了對(duì)主題（Post）的引用的聚合。其關(guān)系可以如下表示：

image

這樣的設(shè)計(jì)甜刻，會(huì)讓有些朋友感到不適應(yīng)绍撞，原因是我們無(wú)法直接從Post實(shí)體獲得其下所有的Reply實(shí)體，那么對(duì)于“通過(guò)給定的Post得院，獲得與它相關(guān)的所有Reply信息”這樣的用例傻铣，在實(shí)現(xiàn)上就不那么直接。此時(shí)祥绞，我們需要在應(yīng)用層非洲，通過(guò)Reply的倉(cāng)儲(chǔ)來(lái)獲得鸭限，比如：

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)用層，或許你會(huì)覺(jué)得两踏，這樣做是不是把業(yè)務(wù)邏輯遷移到了應(yīng)用層败京，導(dǎo)致領(lǐng)域模型失血。其實(shí)不然梦染，在這里赡麦，應(yīng)用層并沒(méi)有參與任何業(yè)務(wù)邏輯，從倉(cāng)儲(chǔ)讀取領(lǐng)域?qū)ο笠约皩㈩I(lǐng)域?qū)ο筠D(zhuǎn)換成數(shù)據(jù)傳輸對(duì)象（DTO）帕识，這些并不屬于業(yè)務(wù)邏輯的范疇：因?yàn)閺念I(lǐng)域模型和業(yè)務(wù)邏輯的角度看隧甚，它們并不能知道什么是倉(cāng)儲(chǔ)、什么是規(guī)約渡冻、什么是數(shù)據(jù)傳輸對(duì)象。應(yīng)用層在這里起到了任務(wù)協(xié)調(diào)忧便、數(shù)據(jù)轉(zhuǎn)換等作用族吻。不僅如此，應(yīng)用層甚至還可以包含業(yè)務(wù)規(guī)則引擎以及工作流的實(shí)現(xiàn)（workflow）珠增。