建站
咨詢
售后
建站咨詢
新聞中心
[[411161]]
主要從事網頁設計、PC網站建設（電腦版網站建設）、wap網站建設（手機版網站建設）、成都響應式網站建設、程序開發(fā)、微網站、微信平臺小程序開發(fā)等，憑借多年來在互聯(lián)網的打拼，我們在互聯(lián)網網站建設行業(yè)積累了豐富的成都網站設計、成都網站制作、網絡營銷經驗，集策劃、開發(fā)、設計、營銷、管理等多方位專業(yè)化運作于一體，具備承接不同規(guī)模與類型的建設項目的能力。
依稀記得我第一次設計一個系統(tǒng)的時候，畫了一堆UML（Unified Modeling Language，統(tǒng)一建模語言）圖，面對Class Diagram（其實就是領域模型），糾結了好久，不知道如何落地。 因為，如果按照這個類圖去落數(shù)據庫的話，看起來很奇怪，有點繁瑣。 可是不按照這個類圖落庫的話，又不知道這個類圖畫了有什么用。
捫心自問，你有多久沒有畫數(shù)據模型和領域模型了？
現(xiàn)在回想起來，我當時的糾結源自于我對領域模型和數(shù)據模型這兩個重要概念的不清楚，先前看過DDD(領域驅動設計)，里面一句話我覺得講的很不錯，一個類型可以充當多個角色，這個角色可以是顯式的(實現(xiàn)了某個接口或基類)，也可以是隱式的(承擔的具體職責和上下文決定)。
但是每次在新的需求下來，出設計方案的時候在數(shù)據模型和領域模型上會耽誤一些時間，根本原因在于對這兩個概念混淆。也因為如此，在設計方案或者在開發(fā)過程中會頻繁修改數(shù)據模型的設計，因為如果底層的邏輯、概念、理論基礎沒搞清楚的話，其構建在其上的系統(tǒng)也會出現(xiàn)問題，非常嚴重的問題。
借鑒DDD(領域驅動設計)的一些設計原則，我覺得有必要花時間認真明晰這兩個概念，幫助大家在工作中，更好的做設計決策。
一 概念定義
數(shù)據模型：面向持久化，數(shù)據的載體。關注的是領域知識，是業(yè)務領域的核心實體，體現(xiàn)了問題域里面的關鍵概念，以及概念之間的聯(lián)系。領域模型建模的關鍵是看模型能否顯性化、清晰的表達業(yè)務語義，擴展性是其次。
領域模型：面向業(yè)務，行為的載體。關注的是數(shù)據存儲，所有的業(yè)務都離不開數(shù)據，都離不開對數(shù)據的CRUD，數(shù)據模型建模的決策因素主要是擴展性、性能等非功能屬性，無需過分考慮業(yè)務語義的表征能力。
一個強調的是實體，另一個強調的是關系，再細想下我們當初建模的時候都是用啥的啥圖-ER圖，這下子就被慢慢帶偏了。設計的數(shù)據模型里面帶了實體聲明也帶了業(yè)務關系，兩者開始混淆。
是的，二者的確有一些共同點，有時候領域模型和數(shù)據模型會長的很像，甚至會趨同，這很正常。但更多的時候，二者是有區(qū)別的。正確的做法應該是有意識地把這兩個模型區(qū)別開來，分別設計，因為他們建模的目標會有所不同。
如下圖所示，數(shù)據模型負責的是數(shù)據存儲面向DB，其要義是擴展性、靈活性、性能。而領域模型負責業(yè)務邏輯的實現(xiàn)，其要義是業(yè)務語義顯性化的表達，以及充分利用OO的特性增加代碼的業(yè)務表征能力。
途中標識灰色的部分其實還可以細分，業(yè)務到模型之間也可進行拆分，涉及到一些命名，這里就不做展開。
在日常開發(fā)過程中，我們在很多的系統(tǒng)業(yè)務設計上，并沒很好的處理數(shù)據模型和領域模型的關系，反而在設計的時候一個是把數(shù)據模型當領域模型，另一個是把領域模型當數(shù)據模型。
二 錯把領域模型當數(shù)據模型
最近在優(yōu)化低代碼那塊的元數(shù)據優(yōu)化，里面涉及到一些元數(shù)據存儲、拓展問題。這塊邏輯大致可以簡單概括:
數(shù)據表單設計時候，用戶可以動態(tài)配置列的屬性以及對列屬性根據對應的數(shù)據類型動態(tài)匹配相應函數(shù)。
對于這個規(guī)則，領域模型很簡單，就是提供了列基本配置信息和屬性配置信息配置數(shù)據，如下圖所示：
如果按照這個思路下去就會存在兩張表meta_field_definition、meta_field_attribute 兩張數(shù)據表，一張用來存儲列的基礎定義，另一張用來定義列的屬性配置以及拓展。
如果我們這個干了，我們就犯了把領域模型當數(shù)據模型的錯誤，這里設計一張數(shù)據表足夠。在原來的元數(shù)據列定義表里面加屬性配置字段fd_attribute 以Json的形式存儲，再基礎表單的基礎上加拓展表fd_extend_feature（當前業(yè)務用不上作為基礎保留的拓展字段）
調整后有什么好處：
-
首先，一張表單的維護成本肯定比多張表的維護成本低
-
其次，其數(shù)據的擴展性更好。比如：針對某種數(shù)據類型要支持某種定制的業(yè)務配置和函數(shù)支持，如果是一張表，我們就需要往屬性表里面繼續(xù)添加新的業(yè)務支持配置。但是如果我們修改為一張表在原有的元數(shù)據中保持不變在屬性拓展里面以JSON格式添加配置即可。
可是，在業(yè)務代碼里面，如果是基于JSON在做事情可不那么美好。我們需要把JSON的數(shù)據對象，轉換成有業(yè)務語義的領域對象，這樣，我們既可以享受數(shù)據模型擴展性帶來的便捷性，又不失領域模型對業(yè)務語義顯性化帶來的代碼可讀性。
三 錯把數(shù)據模型當領域模型
的確，數(shù)據模型最好盡量可擴展，畢竟，改動數(shù)據庫可是個大工程，不管是加字段、減字段，還是加表、刪表，都涉及到不少的工作量。
拿上面的案例來講
可以注意到fd_extend_feature 拓展表所創(chuàng)建的，便于對表的垂直拓展補充。JSON字段也好，垂直表也好，雖然可以很好的解決數(shù)據存儲擴展的問題，但是，我們最好不要把這些擴展（features）當成領域對象來處理，否則，你的代碼根本就不是在面向對象編程，而是在面向擴展字段（features）編程，從而犯了把數(shù)據模型當領域模型的錯誤。更好的做法，應該是把數(shù)據對象（Data Object）轉換成領域對象來處理。但是在處理改字段的時候，如果頻繁操作addFdExtendFeature、getFdExtendFeature是一種典型的把數(shù)據模型當領域模型的錯誤示范。
四 總結
在日常設計和開發(fā)中我們應該是把領域模型、數(shù)據模型區(qū)別開來，讓他們各司其職，從而更合理的架構我們的應用系統(tǒng)。其中，領域模型是面向領域對象的，要盡量具體，盡量語義明確，顯性化的表達業(yè)務語義是其首要任務，擴展性是其次。而數(shù)據模型是面向數(shù)據存儲的，要盡量可擴展。
回歸到主題一個類型可以充當多個角色，這個角色可以是顯式的（實現(xiàn)了某個接口或基類），也可以是隱式的（承擔的具體職責和上下文決定），
-
數(shù)據模型：面向持久化，數(shù)據的載體。
-
領域模型：面向業(yè)務，行為的載體。
標題名稱：架構上如何設計領域模型和數(shù)據模型？
標題路徑：http://m.fisionsoft.com.cn/article/dhciohg.html
