大數(shù)據(jù)中領域模型和數(shù)據(jù)模型怎么理解

這期內容當中小編將會給大家?guī)碛嘘P大數(shù)據(jù)中領域模型和數(shù)據(jù)模型怎么理解，文章內容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

依稀記得我第一次設計一個系統(tǒng)的時候，畫了一堆UML圖，面對Class  Diagram(其實就是領域模型)，糾結了好久，不知道如何落地。因為，如果按照這個類圖去落數(shù)據(jù)庫的話，看起來很奇怪，有點繁瑣?？墒遣话凑者@個類圖落庫的話，又不知道這個類圖畫了有什么用。

現(xiàn)在回想起來，我當時的糾結源自于我對領域模型和數(shù)據(jù)模型這兩個重要概念的不清楚。最近，我發(fā)現(xiàn)對這兩個概念的混淆不是個例，而是非常普遍的現(xiàn)象。其結果就是，小到會影響一些模塊設計的不合理性，大到會影響像業(yè)務中臺這樣重大技術決策，因為如果底層的邏輯、概念、理論基礎沒搞清楚的話，其構建在其上的系統(tǒng)也會出現(xiàn)問題，非常嚴重的問題。

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

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

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

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

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

這兩個模型之所以容易被混淆，是因為兩者都強調實體(Entity)，都強調關系(Relationship)，這可不，我們傳統(tǒng)的數(shù)據(jù)庫的數(shù)據(jù)模型建模就是用的ER圖啊。

是的，二者的確有一些共同點，有時候領域模型和數(shù)據(jù)模型會長的很像，甚至會趨同，這很正常。但更多的時候，二者是有區(qū)別的。正確的做法應該是有意識的把這兩個模型區(qū)別開來，分別設計，因為他們建模的目標會有所不同。如下圖所示，數(shù)據(jù)模型負責的是數(shù)據(jù)存儲，其要義是擴展性、靈活性、性能。而領域模型負責業(yè)務邏輯的實現(xiàn)，其要義是業(yè)務語義顯性化的表達，以及充分利用OO的特性增加代碼的業(yè)務表征能力。

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

錯把領域模型當數(shù)據(jù)模型

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

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

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

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

這樣做的好處很明顯：

• 首先，維護一張數(shù)據(jù)庫表肯定比兩張的成本要小。

• 其次，其數(shù)據(jù)的擴展性更好。比如，新需求來了，需要增加一個建議價格(suggest  price)區(qū)間，如果是兩張表的話，我需要在price_range中加兩個新字段，而如果是json存儲的話，數(shù)據(jù)模型可以保持不變。

可是，在業(yè)務代碼里面，如果是基于json在做事情可不那么美好。我們需要把json的數(shù)據(jù)對象，轉換成有業(yè)務語義的領域對象，這樣，我們既可以享受數(shù)據(jù)模型擴展性帶來的便捷性，又不失領域模型對業(yè)務語義顯性化帶來的代碼可讀性。

錯把數(shù)據(jù)模型當領域模型

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

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

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

JSON字段也好，垂直表也好，雖然可以很好的解決數(shù)據(jù)存儲擴展的問題。但是，我們最好不要把這些擴展(features)當成領域對象來處理，否則，你的代碼根本就不是在面向對象編程，而是在面向擴展字段(features)編程，從而犯了把數(shù)據(jù)模型當領域模型的錯誤。更好的做法，應該是把數(shù)據(jù)對象(Data  Object)轉換成領域對象來處理。

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

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

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

上面展示了因為混淆領域模型和數(shù)據(jù)模型，帶來的問題。正確的做法應該是把領域模型、數(shù)據(jù)模型區(qū)別開來，讓他們各司其職，從而更合理的架構我們的應用系統(tǒng)。

其中，領域模型是面向領域對象的，要盡量具體，盡量語明確，顯性化的表達業(yè)務語義是其首要任務，擴展性是其次。而數(shù)據(jù)模型是面向數(shù)據(jù)存儲的，要盡量可擴展。

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

此外，教科書上教導我們在做關系數(shù)據(jù)庫設計的時候，要滿足3NF(三范式)，然而，在實際工作中，我們經(jīng)常會因為性能、擴展性的原因故意打破這個原則，比如我們會通過數(shù)據(jù)冗余提升訪問性能，我們會通過元數(shù)據(jù)、垂直表、擴展字段提升表的擴展性。

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

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

關于擴展的更多思考

最后，再給一個思考題吧。

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

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

只是，我不清楚從元數(shù)據(jù)到領域對象的映射，salesforce具體是怎么做的，是通過他們的語法糖apex?如果沒有領域對象，他們的業(yè)務代碼要怎么寫呢?反正據(jù)在salesforce里面做vendor的同學說，他們所謂的low  code，里面還是有很多用apex寫的代碼，而且可維護性一般。

anyway，我們絕大部分的應用都是面向確定問題域的，不需要像Salesforce那樣提供“無邊際”的擴展能力。在這種情況下，我認為，領域對象是最好的連接數(shù)據(jù)模型和業(yè)務邏輯的橋梁。

上述就是小編為大家分享的大數(shù)據(jù)中領域模型和數(shù)據(jù)模型怎么理解了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業(yè)資訊頻道。