利用聚合概念指導(dǎo)MongoDB的Schema設(shè)計(jì)
習(xí)慣的力量強(qiáng)大卻往往無法察覺。往往不經(jīng)意之間，陷入習(xí)慣的陷阱中卻不自知。
在我們的項(xiàng)目中，為了能夠保存分析報(bào)表以及用戶設(shè)置的報(bào)表查詢條件，我們將這些信息視為報(bào)表元數(shù)據(jù)存儲(chǔ)在MongoDB中。要存儲(chǔ)的元數(shù)據(jù)包括：
- 報(bào)表分類(ReportCategory)
- 報(bào)表(Report)
- 報(bào)表查詢條件(QeuryCondition)
一個(gè)報(bào)表分類會(huì)包含多個(gè)報(bào)表，同一個(gè)報(bào)表只能屬于一個(gè)分類。每個(gè)報(bào)表提供了多個(gè)標(biāo)準(zhǔn)查詢條件和多個(gè)用戶自定義查詢條件。
我需要為這些元數(shù)據(jù)設(shè)計(jì)MongoDB的DB Schema。最初考慮將這三個(gè)概念合起來定義為元數(shù)據(jù)表的一條記錄。之后想到對(duì)于一個(gè)報(bào)表而言，需要頻繁對(duì)報(bào)表的查詢條件進(jìn)行增刪操作，似乎又應(yīng)該將查詢條件單獨(dú)分離出來。那么報(bào)表分類與報(bào)表呢?是否將報(bào)表也獨(dú)立出來才合適?對(duì)于MongoDB這樣的Document數(shù)據(jù)庫而言，將Report作為ReportCategory的embedded屬性也是可行的，至少不會(huì)像關(guān)系型數(shù)據(jù)庫那樣會(huì)產(chǎn)生數(shù)據(jù)冗余。倘若要分開，當(dāng)需要查詢某個(gè)分類下的所有報(bào)表時(shí)，還得多余地做一次Link。
好糾結(jié)啊!似乎怎么設(shè)計(jì)都是可行的，又仿佛總有不如意處。
正在思索中，突然想起對(duì)于這樣面向文檔的NoSQL數(shù)據(jù)庫而言，使用聚合(Aggregate)來觀察表記錄會(huì)更加恰當(dāng)。這個(gè)想法恍若閃電般迅捷而銳利，猛地撞向腦中的思緒，一下子點(diǎn)燃了我的設(shè)計(jì)思維。
這里所謂“聚合”，非面向?qū)ο笾斜磉_(dá)對(duì)象關(guān)系的概念，而是領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)(DDD)對(duì)對(duì)象邊界的思考。關(guān)于聚合(Aggregate)的設(shè)計(jì)，我根據(jù)過往的經(jīng)驗(yàn)，整理出五條設(shè)計(jì)原則：
- 聚合作為一種邊界，主要用于維護(hù)業(yè)務(wù)完整性，此時(shí)應(yīng)遵循業(yè)務(wù)規(guī)則中定義的不變量(Invariant)
- 作為聚合邊界內(nèi)的非聚合根實(shí)體對(duì)象，若可能被別的調(diào)用者單獨(dú)調(diào)用，則應(yīng)該作為單獨(dú)的聚合分離出來
- 在聚合邊界內(nèi)的非聚合根對(duì)象，與聚合根之間應(yīng)該存在直接或間接的引用關(guān)系，且可以通過對(duì)象的引用方式;若必須采用Id來引用，則說明被引用的對(duì)象不屬于該聚合
- 若一個(gè)對(duì)象缺少另一個(gè)對(duì)象作為其主對(duì)象就不可能存在，則該對(duì)象一定屬于該主對(duì)象的聚合邊界內(nèi)
- 若一個(gè)實(shí)體對(duì)象，可能被多個(gè)聚合引用，則該實(shí)體對(duì)象應(yīng)首先考慮作為單獨(dú)的聚合
這些設(shè)計(jì)原則都是我在探索聚合設(shè)計(jì)時(shí)的一些思考，多次實(shí)踐下來，竊以為頗有指導(dǎo)價(jià)值。這里不再鋪開，留待以后的文章詳述。單說本例，我們?cè)撊绾芜\(yùn)用這些原則來思考ReportCategory、Report與QueryCondition之間的關(guān)系?
顯然，套用這些原則，我認(rèn)為前面糾纏不清的混亂思路已可迎刃而解。從業(yè)務(wù)完整性看，Report雖屬于ReportCategory，但二者未嘗有強(qiáng)的約束關(guān)系，即不存在業(yè)務(wù)上的不變量(Invariant)。例如ReportCategory可以沒有Report，成為一個(gè)空的分類，我們也可以撇開ReportCategory，單獨(dú)查詢所有的Report。倘若我們將Report放到ReportCategory聚合中，由于Report可能會(huì)被單獨(dú)調(diào)用，聚合的邊界保護(hù)反而成為了障礙，不合理。
于是，我們可以得出***個(gè)結(jié)論：ReportCategory和Report應(yīng)該屬于兩個(gè)不同的聚合。
基于第四條原則，我們可以提出問題：當(dāng)QueryCondition缺少Report對(duì)象后，還有存在意義嗎?答案一目了然，沒有Report，就沒有QueryCondition。皮之不存毛將焉附!第二個(gè)結(jié)論自然得來：Report與QueryCondition應(yīng)屬于同一個(gè)聚合。于是，模型呼之欲出：
上圖是領(lǐng)域模型而非數(shù)據(jù)模型。站在領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的角度，這才是正確的打開姿勢。那么，使用該領(lǐng)域模型去指導(dǎo)MongoDB的Schema設(shè)計(jì)，是否有將領(lǐng)域混入技術(shù)實(shí)現(xiàn)之嫌呢?從設(shè)計(jì)方向看，先考慮領(lǐng)域模型才是正解，DB的技術(shù)實(shí)現(xiàn)應(yīng)為了滿足該領(lǐng)域模型而設(shè)計(jì)。只有當(dāng)領(lǐng)域模型可能阻礙技術(shù)實(shí)現(xiàn)，又或者依據(jù)領(lǐng)域模型得到的Schema設(shè)計(jì)不滿足性能或其他質(zhì)量屬性需求時(shí)，才應(yīng)該反過來調(diào)整領(lǐng)域模型。對(duì)于MongoDB這種面向Document的數(shù)據(jù)庫，以聚合概念指導(dǎo)Schema設(shè)計(jì)，可謂水到渠成，不僅沒有違和之感，反而讓Repository的實(shí)現(xiàn)變得更加簡單、自然。
在項(xiàng)目開發(fā)過程中，我先入為主地做了技術(shù)選型，從而習(xí)慣性地開始針對(duì)MongoDB進(jìn)行Schema設(shè)計(jì)，反而忘了領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的指導(dǎo)原則。技術(shù)人員對(duì)技術(shù)實(shí)現(xiàn)往往見獵心喜，因而忽略了領(lǐng)域設(shè)計(jì)的驅(qū)動(dòng)力，慎之慎之!
【本文為51CTO專欄作者“張逸”原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】
