查看原文

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

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

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

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

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

使用正確的統一語言。由於領域模型是問題域的表示，因此必須正確地命名其元素、必須確保無論是客戶或承包商都使用同一種語言（統一語言）。統一語言很重要，因為它可以最大限度地減少誤解的可能性，而這些額外的誤解可能降低向客戶提供產品的質量。

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

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

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

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

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

【譯文】一個設計精良的領域驅動模型的五個特征