[[411161]]

依稀記得我第一次設(shè)計一個系統(tǒng)的時候，畫了一堆UML（Unified Modeling Language，統(tǒng)一建模語言）圖，面對Class Diagram（其實就是領(lǐng)域模型），糾結(jié)了好久，不知道如何落地。 因為，如果按照這個類圖去落數(shù)據(jù)庫的話，看起來很奇怪，有點繁瑣。 可是不按照這個類圖落庫的話，又不知道這個類圖畫了有什么用。

捫心自問，你有多久沒有畫數(shù)據(jù)模型和領(lǐng)域模型了？

現(xiàn)在回想起來，我當(dāng)時的糾結(jié)源自于我對領(lǐng)域模型和數(shù)據(jù)模型這兩個重要概念的不清楚，先前看過DDD(領(lǐng)域驅(qū)動設(shè)計)，里面一句話我覺得講的很不錯，一個類型可以充當(dāng)多個角色，這個角色可以是顯式的(實現(xiàn)了某個接口或基類)，也可以是隱式的(承擔(dān)的具體職責(zé)和上下文決定)。

但是每次在新的需求下來，出設(shè)計方案的時候在數(shù)據(jù)模型和領(lǐng)域模型上會耽誤一些時間，根本原因在于對這兩個概念混淆。也因為如此，在設(shè)計方案或者在開發(fā)過程中會頻繁修改數(shù)據(jù)模型的設(shè)計，因為如果底層的邏輯、概念、理論基礎(chǔ)沒搞清楚的話，其構(gòu)建在其上的系統(tǒng)也會出現(xiàn)問題，非常嚴(yán)重的問題。

借鑒DDD(領(lǐng)域驅(qū)動設(shè)計)的一些設(shè)計原則，我覺得有必要花時間認真明晰這兩個概念，幫助大家在工作中，更好的做設(shè)計決策。

一  概念定義

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

領(lǐng)域模型：面向業(yè)務(wù)，行為的載體。關(guān)注的是數(shù)據(jù)存儲，所有的業(yè)務(wù)都離不開數(shù)據(jù)，都離不開對數(shù)據(jù)的CRUD，數(shù)據(jù)模型建模的決策因素主要是擴展性、性能等非功能屬性，無需過分考慮業(yè)務(wù)語義的表征能力。

一個強調(diào)的是實體，另一個強調(diào)的是關(guān)系，再細想下我們當(dāng)初建模的時候都是用啥的啥圖-ER圖，這下子就被慢慢帶偏了。設(shè)計的數(shù)據(jù)模型里面帶了實體聲明也帶了業(yè)務(wù)關(guān)系，兩者開始混淆。

是的，二者的確有一些共同點，有時候領(lǐng)域模型和數(shù)據(jù)模型會長的很像，甚至?xí)呁?，這很正常。但更多的時候，二者是有區(qū)別的。正確的做法應(yīng)該是有意識地把這兩個模型區(qū)別開來，分別設(shè)計，因為他們建模的目標(biāo)會有所不同。

如下圖所示，數(shù)據(jù)模型負責(zé)的是數(shù)據(jù)存儲面向DB，其要義是擴展性、靈活性、性能。而領(lǐng)域模型負責(zé)業(yè)務(wù)邏輯的實現(xiàn)，其要義是業(yè)務(wù)語義顯性化的表達，以及充分利用OO的特性增加代碼的業(yè)務(wù)表征能力。

途中標(biāo)識灰色的部分其實還可以細分，業(yè)務(wù)到模型之間也可進行拆分，涉及到一些命名，這里就不做展開。

在日常開發(fā)過程中，我們在很多的系統(tǒng)業(yè)務(wù)設(shè)計上，并沒很好的處理數(shù)據(jù)模型和領(lǐng)域模型的關(guān)系，反而在設(shè)計的時候一個是把數(shù)據(jù)模型當(dāng)領(lǐng)域模型，另一個是把領(lǐng)域模型當(dāng)數(shù)據(jù)模型。

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

最近在優(yōu)化低代碼那塊的元數(shù)據(jù)優(yōu)化，里面涉及到一些元數(shù)據(jù)存儲、拓展問題。這塊邏輯大致可以簡單概括:

數(shù)據(jù)表單設(shè)計時候，用戶可以動態(tài)配置列的屬性以及對列屬性根據(jù)對應(yīng)的數(shù)據(jù)類型動態(tài)匹配相應(yīng)函數(shù)。

對于這個規(guī)則，領(lǐng)域模型很簡單，就是提供了列基本配置信息和屬性配置信息配置數(shù)據(jù)，如下圖所示：

如果按照這個思路下去就會存在兩張表meta_field_definition、meta_field_attribute 兩張數(shù)據(jù)表，一張用來存儲列的基礎(chǔ)定義，另一張用來定義列的屬性配置以及拓展。

如果我們這個干了，我們就犯了把領(lǐng)域模型當(dāng)數(shù)據(jù)模型的錯誤，這里設(shè)計一張數(shù)據(jù)表足夠。在原來的元數(shù)據(jù)列定義表里面加屬性配置字段fd_attribute 以Json的形式存儲，再基礎(chǔ)表單的基礎(chǔ)上加拓展表fd_extend_feature（當(dāng)前業(yè)務(wù)用不上作為基礎(chǔ)保留的拓展字段）

調(diào)整后有什么好處：

• 首先，一張表單的維護成本肯定比多張表的維護成本低

• 其次，其數(shù)據(jù)的擴展性更好。比如：針對某種數(shù)據(jù)類型要支持某種定制的業(yè)務(wù)配置和函數(shù)支持，如果是一張表，我們就需要往屬性表里面繼續(xù)添加新的業(yè)務(wù)支持配置。但是如果我們修改為一張表在原有的元數(shù)據(jù)中保持不變在屬性拓展里面以JSON格式添加配置即可。

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

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

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

拿上面的案例來講

可以注意到fd_extend_feature 拓展表所創(chuàng)建的，便于對表的垂直拓展補充。JSON字段也好，垂直表也好，雖然可以很好的解決數(shù)據(jù)存儲擴展的問題，但是，我們最好不要把這些擴展（features）當(dāng)成領(lǐng)域?qū)ο髞硖幚?，否則，你的代碼根本就不是在面向?qū)ο缶幊?，而是在面向擴展字段（features）編程，從而犯了把數(shù)據(jù)模型當(dāng)領(lǐng)域模型的錯誤。更好的做法，應(yīng)該是把數(shù)據(jù)對象（Data Object）轉(zhuǎn)換成領(lǐng)域?qū)ο髞硖幚?。但是在處理改字段的時候，如果頻繁操作addFdExtendFeature、getFdExtendFeature是一種典型的把數(shù)據(jù)模型當(dāng)領(lǐng)域模型的錯誤示范。

四 總結(jié)

在日常設(shè)計和開發(fā)中我們應(yīng)該是把領(lǐng)域模型、數(shù)據(jù)模型區(qū)別開來，讓他們各司其職，從而更合理的架構(gòu)我們的應(yīng)用系統(tǒng)。其中，領(lǐng)域模型是面向領(lǐng)域?qū)ο蟮?，要盡量具體，盡量語義明確，顯性化的表達業(yè)務(wù)語義是其首要任務(wù)，擴展性是其次。而數(shù)據(jù)模型是面向數(shù)據(jù)存儲的，要盡量可擴展。

回歸到主題一個類型可以充當(dāng)多個角色，這個角色可以是顯式的（實現(xiàn)了某個接口或基類），也可以是隱式的（承擔(dān)的具體職責(zé)和上下文決定），

• 數(shù)據(jù)模型：面向持久化，數(shù)據(jù)的載體。

• 領(lǐng)域模型：面向業(yè)務(wù)，行為的載體。