依稀記得我第一次設(shè)計(jì)一個(gè)系統(tǒng)的時(shí)候，畫了一堆UML圖，面對(duì)Class Diagram(其實(shí)就是領(lǐng)域模型)，糾結(jié)了好久，不知道如何落地。因?yàn)椋绻凑者@個(gè)類圖去落數(shù)據(jù)庫的話，看起來很奇怪，有點(diǎn)繁瑣。可是不按照這個(gè)類圖落庫的話，又不知道這個(gè)類圖畫了有什么用。

現(xiàn)在回想起來，我當(dāng)時(shí)的糾結(jié)源自于我對(duì)領(lǐng)域模型和數(shù)據(jù)模型這兩個(gè)重要概念的不清楚。最近，我發(fā)現(xiàn)對(duì)這兩個(gè)概念的混淆不是個(gè)例，而是非常普遍的現(xiàn)象。其結(jié)果就是，小到會(huì)影響一些模塊設(shè)計(jì)的不合理性，大到會(huì)影響像業(yè)務(wù)中臺(tái)這樣重大技術(shù)決策，因?yàn)槿绻讓拥倪壿嫛⒏拍睢⒗碚摶A(chǔ)沒搞清楚的話，其構(gòu)建在其上的系統(tǒng)也會(huì)出現(xiàn)問題，非常嚴(yán)重的問題。

鑒于很少看到有人對(duì)這個(gè)話題進(jìn)行比較深入的研究和探討，我覺得有必要花時(shí)間認(rèn)真明晰這兩個(gè)概念，幫助大家在工作中，更好的做設(shè)計(jì)決策。

領(lǐng)域模型和數(shù)據(jù)模型的概念定義

領(lǐng)域模型關(guān)注的是領(lǐng)域知識(shí)，是業(yè)務(wù)領(lǐng)域的核心實(shí)體，體現(xiàn)了問題域里面的關(guān)鍵概念，以及概念之間的聯(lián)系。領(lǐng)域模型建模的關(guān)鍵是看模型能否顯性化、清晰的表達(dá)業(yè)務(wù)語義，擴(kuò)展性是其次。

數(shù)據(jù)模型關(guān)注的是數(shù)據(jù)存儲(chǔ)，所有的業(yè)務(wù)都離不開數(shù)據(jù)，都離不開對(duì)數(shù)據(jù)的CRUD，數(shù)據(jù)模型建模的決策因素主要是擴(kuò)展性、性能等非功能屬性，無需過分考慮業(yè)務(wù)語義的表征能力。

按照Robert在《整潔架構(gòu)》里面的觀點(diǎn)，領(lǐng)域模型是核心，數(shù)據(jù)模型是技術(shù)細(xì)節(jié)。然而現(xiàn)實(shí)情況是，二者都很重要。

這兩個(gè)模型之所以容易被混淆，是因?yàn)閮烧叨紡?qiáng)調(diào)實(shí)體(Entity)，都強(qiáng)調(diào)關(guān)系(Relationship)，這可不，我們傳統(tǒng)的數(shù)據(jù)庫的數(shù)據(jù)模型建模就是用的ER圖啊。

是的，二者的確有一些共同點(diǎn)，有時(shí)候領(lǐng)域模型和數(shù)據(jù)模型會(huì)長的很像，甚至?xí)呁@很正常。但更多的時(shí)候，二者是有區(qū)別的。正確的做法應(yīng)該是有意識(shí)的把這兩個(gè)模型區(qū)別開來，分別設(shè)計(jì)，因?yàn)樗麄兘５哪繕?biāo)會(huì)有所不同。如下圖所示，數(shù)據(jù)模型負(fù)責(zé)的是數(shù)據(jù)存儲(chǔ)，其要義是擴(kuò)展性、靈活性、性能。而領(lǐng)域模型負(fù)責(zé)業(yè)務(wù)邏輯的實(shí)現(xiàn)，其要義是業(yè)務(wù)語義顯性化的表達(dá)，以及充分利用OO的特性增加代碼的業(yè)務(wù)表征能力。

然而，現(xiàn)實(shí)情況是，我們很多的業(yè)務(wù)系統(tǒng)設(shè)計(jì)，并沒有很好的區(qū)分二者的關(guān)系。經(jīng)常會(huì)犯兩個(gè)錯(cuò)誤，一個(gè)是把領(lǐng)域模型當(dāng)數(shù)據(jù)模型，另一個(gè)是把數(shù)據(jù)模型當(dāng)領(lǐng)域模型。

錯(cuò)把領(lǐng)域模型當(dāng)數(shù)據(jù)模型

這幾天我在做一個(gè)報(bào)價(jià)優(yōu)化的項(xiàng)目，里面涉及到報(bào)價(jià)規(guī)則的問題，這塊的業(yè)務(wù)邏輯大意是說，對(duì)于不同的商品(通過類目、品牌、供應(yīng)商類型等維度區(qū)分)，我們會(huì)給出不同的價(jià)格區(qū)間，然后來判斷商家的報(bào)價(jià)是否應(yīng)該被自動(dòng)審核(autoApprove)通過，還是應(yīng)該被自動(dòng)攔截(autoBlock)

對(duì)于這個(gè)規(guī)則，領(lǐng)域模型很簡單，就是提供了價(jià)格管控需要的配置數(shù)據(jù)，如下圖所示：

如果按照這個(gè)領(lǐng)域模型去設(shè)計(jì)我們的存儲(chǔ)的話，自然是需要兩張表：pricerule和pricerange，一張用來存價(jià)格規(guī)則，一張是用來存價(jià)格區(qū)間。

如果這樣去設(shè)計(jì)數(shù)據(jù)模型，我們就犯了把領(lǐng)域模型當(dāng)數(shù)據(jù)模型的錯(cuò)誤。這里，更合適的做法是一張表就夠了，把pricerange作為一個(gè)字段在pricerule中用一個(gè)字段存儲(chǔ)，如下圖所示，里面的多個(gè)價(jià)格區(qū)間信息用一個(gè)json字段去存取就好了。

這樣做的好處很明顯：

• 首先，維護(hù)一張數(shù)據(jù)庫表肯定比兩張的成本要小。
• 其次，其數(shù)據(jù)的擴(kuò)展性更好。比如，新需求來了，需要增加一個(gè)建議價(jià)格(suggest price)區(qū)間，如果是兩張表的話，我需要在price_range中加兩個(gè)新字段，而如果是json存儲(chǔ)的話，數(shù)據(jù)模型可以保持不變。

可是，在業(yè)務(wù)代碼里面，如果是基于json在做事情可不那么美好。我們需要把json的數(shù)據(jù)對(duì)象，轉(zhuǎn)換成有業(yè)務(wù)語義的領(lǐng)域?qū)ο螅@樣，我們既可以享受數(shù)據(jù)模型擴(kuò)展性帶來的便捷性，又不失領(lǐng)域模型對(duì)業(yè)務(wù)語義顯性化帶來的代碼可讀性。

錯(cuò)把數(shù)據(jù)模型當(dāng)領(lǐng)域模型

的確，數(shù)據(jù)模型最好盡量可擴(kuò)展，畢竟，改動(dòng)數(shù)據(jù)庫可是個(gè)大工程，不管是加字段、減字段，還是加表、刪表，都涉及到不少的工作量。

說到數(shù)據(jù)模型的擴(kuò)展設(shè)計(jì)經(jīng)典之作，非阿里的業(yè)務(wù)中臺(tái)莫屬，核心的商品、訂單、支付、物流4張表，得益于良好的擴(kuò)展性設(shè)計(jì)，就支撐了阿里幾十個(gè)業(yè)務(wù)的成千上萬的業(yè)務(wù)場景。

拿商品中臺(tái)來說，它用一張auction_extend垂直表，就解決了所有業(yè)務(wù)商品數(shù)據(jù)存儲(chǔ)擴(kuò)展性的需求。理論上來說，這種數(shù)據(jù)模型可以滿足無限的業(yè)務(wù)擴(kuò)展。

JSON字段也好，垂直表也好，雖然可以很好的解決數(shù)據(jù)存儲(chǔ)擴(kuò)展的問題。但是，我們最好不要把這些擴(kuò)展(features)當(dāng)成領(lǐng)域?qū)ο髞硖幚恚駝t，你的代碼根本就不是在面向?qū)ο缶幊蹋窃诿嫦驍U(kuò)展字段(features)編程，從而犯了把數(shù)據(jù)模型當(dāng)領(lǐng)域模型的錯(cuò)誤。更好的做法，應(yīng)該是把數(shù)據(jù)對(duì)象(Data Object)轉(zhuǎn)換成領(lǐng)域?qū)ο髞硖幚怼?/p>

如下所示，這種代碼里面到處是getFeature、addFeature的寫法，是一種典型的把數(shù)據(jù)模型當(dāng)領(lǐng)域模型的錯(cuò)誤示范。

上面展示的代碼，是一個(gè)在某中臺(tái)上寫業(yè)務(wù)代碼的同學(xué)，在離職那天發(fā)給我看的，他說他受夠了這種亂七八糟的代碼，但作為一個(gè)底層小P，又無能改變局面，無奈之下，只能選擇離開。

領(lǐng)域模型和數(shù)據(jù)模型各司其職

上面展示了因?yàn)榛煜I(lǐng)域模型和數(shù)據(jù)模型，帶來的問題。正確的做法應(yīng)該是把領(lǐng)域模型、數(shù)據(jù)模型區(qū)別開來，讓他們各司其職，從而更合理的架構(gòu)我們的應(yīng)用系統(tǒng)。

其中，領(lǐng)域模型是面向領(lǐng)域?qū)ο蟮模M量具體，盡量語明確，顯性化的表達(dá)業(yè)務(wù)語義是其首要任務(wù)，擴(kuò)展性是其次。而數(shù)據(jù)模型是面向數(shù)據(jù)存儲(chǔ)的，要盡量可擴(kuò)展。

在具體落地的時(shí)候，我們可以采用COLA的架構(gòu)思想，使用gateway作為數(shù)據(jù)對(duì)象(Data Object)和領(lǐng)域?qū)ο?Entity)之間的轉(zhuǎn)義網(wǎng)關(guān)，其中，gateway除了轉(zhuǎn)義的作用，還起到了防腐解耦的作用，解除了業(yè)務(wù)代碼對(duì)底層數(shù)據(jù)(DO、DTO等)的直接依賴，從而提升系統(tǒng)的可維護(hù)性。

此外，教科書上教導(dǎo)我們?cè)谧鲫P(guān)系數(shù)據(jù)庫設(shè)計(jì)的時(shí)候，要滿足3NF(三范式)，然而，在實(shí)際工作中，我們經(jīng)常會(huì)因?yàn)樾阅堋U(kuò)展性的原因故意打破這個(gè)原則，比如我們會(huì)通過數(shù)據(jù)冗余提升訪問性能，我們會(huì)通過元數(shù)據(jù)、垂直表、擴(kuò)展字段提升表的擴(kuò)展性。

業(yè)務(wù)場景不一樣，對(duì)數(shù)據(jù)擴(kuò)展的訴求也不一樣，像pricerule這種簡單的配置數(shù)據(jù)擴(kuò)展，json就能勝任。復(fù)雜一點(diǎn)的，像auctionextend這種垂直表也是不錯(cuò)的選擇。

wait，有同學(xué)說，你這樣做，數(shù)據(jù)是可擴(kuò)展了，可數(shù)據(jù)查詢?cè)趺唇鉀Q呢?總不能用join表，或者用like吧，實(shí)際上，對(duì)一些配置類的數(shù)據(jù)，或者數(shù)據(jù)量不大的數(shù)據(jù)，完全可以like。然而，對(duì)于像阿里商品、交易這樣的海量數(shù)據(jù)，當(dāng)然不能like，不過這個(gè)問題，很容易通過讀寫分離，構(gòu)建search的辦法解決。

關(guān)于擴(kuò)展的更多思考

最后，再給一個(gè)思考題吧。

前面提到的數(shù)據(jù)擴(kuò)展，還都是領(lǐng)域內(nèi)的有限擴(kuò)展。如果我連業(yè)務(wù)領(lǐng)域是什么還不知道，能不能做數(shù)據(jù)擴(kuò)展呢? 可以的，salesforce的force.com就是這么做的，其底層數(shù)據(jù)存儲(chǔ)完全是元數(shù)據(jù)驅(qū)動(dòng)的(metadata-driven)，他用一張有500個(gè)匿名字段的表，去支撐所有的SaaS業(yè)務(wù)，每個(gè)字段的實(shí)際表意是通過元數(shù)據(jù)去描述的。如下圖所示，value0到value500都是預(yù)留的業(yè)務(wù)字段，具體代表什么意思，由metadata去定義。

說實(shí)話，這種實(shí)現(xiàn)方式的確是一個(gè)很有想法，很大膽的設(shè)計(jì)，也的確支撐了上面數(shù)以千計(jì)的SaaS應(yīng)用和salesforce千億美金的市值。

只是，我不清楚從元數(shù)據(jù)到領(lǐng)域?qū)ο蟮挠成洌瑂alesforce具體是怎么做的，是通過他們的語法糖apex?如果沒有領(lǐng)域?qū)ο螅麄兊臉I(yè)務(wù)代碼要怎么寫呢?反正據(jù)在salesforce里面做vendor的同學(xué)說，他們所謂的low code，里面還是有很多用apex寫的代碼，而且可維護(hù)性一般。

anyway，我們絕大部分的應(yīng)用都是面向確定問題域的，不需要像Salesforce那樣提供“無邊際”的擴(kuò)展能力。在這種情況下，我認(rèn)為，領(lǐng)域?qū)ο笫亲詈玫倪B接數(shù)據(jù)模型和業(yè)務(wù)邏輯的橋梁。