歡迎光臨
每天分享高質量文章

【譯文】領域模型的五個特征

我在這篇博客文章中,我試圖給領域模型下一個非常合適的定義,我發現我的這些定義都不太妥當,不過,我們還是可以先來看一下wiki百科對領域驅動模型下的定義:

問題解決和軟體工程中的領域模型可以被認為是感興趣的領域(通常稱為問題領域)的概念模型,其描述了各種物體,它們的屬性和關係,以及控制完整性的約束。包含該問題域的模型元素。

聽起來很重要?換句話說,領域模型是每個應用程式的重要組成部分,它是現實世界概念的表示。但是,如何區分好的領域模型和壞的模型呢?由於瞭解領域模型,你也需要瞭解問題域,因此對於這個問題,並沒有明確的答案。在這篇文章中,我打算通過介紹領域模型的五個特征來簡化這個問題的理解難度。

我認為,一個好的領域模型,他應具備以下基本特征:

正確的對問題域進行建模。一個好的領域模型不一定是來自現實世界的精確副本,但它必須以所需的準確度對問題域進行建模。這意味著它必須僅包含與解決給定問題相關的信息。必須從域模型中排除不必要的信息,即使它存在於現實世界中。不過,僅僅包含正確的物體依然不夠,這些物體之間關係也得正確。在你使用這個標準判斷一個領域模型之前,你應當瞭解從問題域中發現的知識,這絕非易事。

使用正確的統一語言。由於領域模型是問題域的表示,因此必須正確地命名其元素、必須確保無論是客戶或承包商都使用同一種語言(統一語言)。統一語言很重要,因為它可以最大限度地減少誤解的可能性,而這些額外的誤解可能降低向客戶提供產品的質量。驗證分析的域模型是否滿足此要求非常簡單,如果一個領域模型中的元素命名準確恰當,那麼客戶顯然能無礙的理解。

領域應擁有和表達與當前問題域相關的完整信息。一個好的領域模型控制對其信息所做的更改。因此它應該提供操作其內容的方法,並禁止對其控制下的信息進行所有其他更改。僅為領域模型的信息提供單個訪問點有兩個主要優點:它減少了重覆代碼並保護了領域模型的完整性。因此,遵循此個方法將導致職責清晰且更不容易出錯的代碼,這應該是每個軟體工程師的標的。此外,如果您需要僅基於領域模型且沒有其他依賴關係的信息,則應將提供此信息的方法放在域模型中。這種方法遵循關註點分離原則,它將通過闡明軟體的體系結構來提高代碼質量。遵循這些方法也將幫助您避免稱為貧血領域模型的反樣式。

提供內置的日誌記錄支持。領域模型應該提供獲取物體的內容序列化成字串的方法,並通過把物件的內容寫入到日誌的做法通常很有用。採用這種方法你不必手動構造日誌的結構,只需將有問題的物件輸出到日誌檔案中,就足以讓你瞭解到相關的操作過程。

良好的單元測試改寫。設計一個好的領域模型,單元測試改寫率顯然是必須考慮的因素(至少對於專業開發者而言)。但我已經瞭解到假設可能是危險的。這就是為什麼我想寫下關於單元測試領域模型的幾句話的原因。雖然我知道精確的指導方針可能很危險,但我認為在這種情況下,可以為任何領域模型的單元測試提供準確的指導。您必須簡單地測試每個方法(不包括getter或setter方法)。

通過本文作者描述了一個設計優良的領域模型的五個特征。通過這篇博文可以幫助讀者辨識領域模型的優劣性,併為設計領域驅動模型提供一些提示。

PS:如果從頭開始設計領域模型,往往會認為需要一個領域驅動設計的操作說明,因此作者推薦大家閱讀 為Eric Evans的《Domain-Driven Design》,這是一本有關領域驅動設計的史詩級巨作,值得每一位開發者閱讀。


已同步到看一看
赞(0)

分享創造快樂