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

查看原文

做者在這篇博客文章中，試圖給領域模型下一個很是合適的定義，可是發現這些定義都不太穩當，不過，咱們仍是能夠先來看一下wiki百科對領域驅動模型下的定義：

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

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

我認爲，一個好的領域模型，他應具有如下基本特徵：

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

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

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

提供內置的日誌記錄支持。領域模型應該提供獲取實體的內容序列化成字符串的方法，並經過把對象的內容寫入到日誌的作法一般頗有用。採用這種方法你沒必要手動構造日誌的結構，只需將有問題的對象輸出到日誌文件中，就足以讓你瞭解到相關的操做過程。

良好的單元測試覆蓋。設計一個好的領域模型，單元測試覆蓋率顯然是必須考慮的因素（至少對於專業開發者而言）。不過對於讀者來講，可能爲每一個領域編寫單元測試或許會有點危險。這就是爲何我想寫下關於單元測試領域模型的幾句話的緣由。即使如此，做者認爲在這種狀況下，爲了可以給任何領域模型的單元測試提供準確的指導，您必須以最簡單的方式測試每一個方法（不包括getter或setter方法）。

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

PS：若是從頭開始設計領域模型，每每會認爲須要一個領域驅動設計的操做說明，所以做者推薦你們閱讀 爲Eric Evans的《Domain-Driven Design》，這是一本有關領域驅動設計的史詩級巨做，值得每一位開發者閱讀。 

做者說這篇寫於8年前的文章，如今他回顧起來以爲寫得比較笨拙，他認爲讀者不該該過多的關注這篇文章給出的建議。