檢視原文

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

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

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

我認為，一個好的領域模型，他應具備以下基本特徵：

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

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

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

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

良好的單元測試覆蓋。良好領域模型的這種特徵是顯而易見的（至少對於專業人士而言），但我已經瞭解到假設可能是危險的。這就是為什麼我想寫下關於單元測試域模型的幾句話的原因。雖然我知道精確的指導方針可能很危險，但我認為在這種情況下，可以為任何領域模型的單元測試提供準確的指導。您必須簡單地測試每個方法（不包括getter或setter方法）。

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

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