如今，有關乾淨程式碼和體系結構的討論很多。關於如何實現它的討論越來越多。羅伯特·C·馬丁（Robert C. Martin）描述的規則是通用的，我認為，我們可以在其他各種情況下使用它們。

在本文中，我想讓他們參考領域模型實現的上下文，這通常是我們系統的核心。我們想擁有一顆乾淨的核心，不是嗎？

從領域驅動設計方法可以知道，我們有兩個空間-問題空間和解決方案空間。Vaughn Vernon在DDD Distilled書中對這些空間的定義如下：

問題空間是您在給定專案的約束下執行高階戰略分析和設計步驟的地方。

解決方案空間是您實際實施問題空間討論確定為核心域的解決方案的地方。

因此，領域模型的實現是解決問題的方法。要討論領域模型是否乾淨，我們必須首先定義清潔解決方案的含義。

什麼是清潔解決方案

我認為每個人都對乾淨解決方案的含義有所定義，或者至少感覺到自己所做的工作是否乾淨。無論如何，讓我描述一下這對我意味著什麼。

首先，指定的解決方案必須解決已定義的問題。這是強制性的。如果無法解決我們問題，即使是最優雅的解決方案，對於該問題空間而言也是一文不值。

其次，從時間的觀點來看，乾淨的解決方案應該是最佳的。它應該花費的時間應該不超過或少於所需的必要時間。

第三，它應該是基於解決簡單問題的基礎上，以簡單性為前提，但要適應變化。我們應該始終保持平衡-不少（無設計或欠設計），也不多（過度設計，請參見YAGNI）。可以用Antoine Airman的Odyssey書中的一句話來總結：

所謂達到完美，不是沒有什麼東西可新增了，而是再沒有什麼東西可移除了

注意：當然，我們應該努力做到完美，因為要意識到我們將永遠無法實現它。

第四，我們應該根據他人的經驗解決問題，並從他們的錯誤中吸取教訓。這就是為什麼架構和設計模式或原則如此有用的原因。我們可以採用某人的解決方案並使之適應我們的需求。而且，我們可以使用其他人建立的工具並使用它們。這是IT世界的顛覆者。

最後但並非最不重要的一點是對解決方案的理解程度。即使經過很長時間，我們也應該能夠理解我們的解決方案。更重要的是，其他人應該能夠理解它。該程式碼讀起來比編寫的要多得多。馬丁·福勒說：

任何傻瓜都可以編寫計算機可以理解的程式碼。好的程式設計師編寫人類可以理解的程式碼。

總而言之，乾淨的解決方案應在簡單時間與複雜性之間取得良好的平衡，從而在最佳時間內準確解決我們的問題。它應該基於其他經驗，常識，使用適當的工具來開發，並且應該易於理解。考慮到所有這些因素，我們如何確定我們的領域模型是一個乾淨的解決方案？

Clean清潔領域模型

1.使用無所不在的統一語言

無處不在的語言是域模型中DDD戰略模式的基礎之一，在其中起著關鍵作用。好像是在編寫商業書籍一樣，商人或業務人士產品經理應該能夠理解所使用的所有邏輯，術語和概念，即使這是計算機程式，他們也無需掌握程式語言！如果我們在定義的上下文中到處使用相同的語言，概念和含義，那麼大家就容易對領域的問題空間及其解決方案增加理解，只會增加專案成功的可能性。

2.行為豐富

顧名思義，領域模型（Domain Model）對領域進行建模。我們在領域中有行為，因此我們的模型也應該有它。如果沒有這種行為，我們將處理所謂的“ 貧血域模型”反模式。對我來說，這實際上是一個資料模型，而不是領域模型。這種模型有時很有用，但當我們具有複雜的行為和邏輯時卻沒有用。它使我們的程式碼具有程式性，並且物件導向程式設計的所有好處都消失了。真正的領域模型具有豐富的行為。

3.被封裝

封裝的領域模型是非常重要的。我們只想向外界公開有關我們模型的最少資訊。我們應該防止業務邏輯洩漏到我們的應用程式邏輯，甚至更糟– GUI。理想情況下，我們應該只在聚合上公開公共方法（領域模型僅有的輸入渠道）。

4.永續性是無感的

永續性無感（PI）是領域模型的另一個眾所周知的概念和理想屬性。我們不想在模型和永續性儲存之間建立高度的耦合。這些是不同的概念，任務和責任。一件事的改變對另一件事的影響應該最小，反之亦然。該區域的低耦合意味著我們的系統可以更好地適應變化。

5.堅持SOLID原則

由於領域模型是物件導向的，因此應遵循所有SOLID原則。例子：

• SRP –一個實體代表一個業務概念。一種方法可以做一件事。一個事件代表一個事實。
• O / C –業務邏輯實現應易於擴充套件而不更改其他位置。在這種情況下，最常使用策略/策略模式。
• LSP –由於堅持繼承規則的組成，遵守LSP規則應該很容易。繼承是類之間的最強耦合，這是我們要避免的
• ISP –我們的域服務或策略的介面應較小–理想情況下應採用一種方法
• DI –要使我們的域模型與其餘應用程式和基礎結構脫鉤，我們需要使用依賴注入和依賴倒置原理。這種組合為我們提供了強大的武器–我們可以在模型中保持一定的抽象水平，在整個模型中使用業務語言，並隱藏技術實現細節。

6.使用領域原語

我看到的大多數程式碼庫都對基本型別進行操作-字串，整數，小數和guid。在領域模型中，此抽象級別絕對太低。

我們應該始終嘗試使用類（實體或值物件）來表達重要的業務概念。通過這種方式，我們的模型更具可讀性，易於維護，行為豐富。另外，我們的程式碼更加安全，因為我們可以在類級別新增驗證。您可以在此處閱讀有關域基元的更多資訊。

7.高效

即使是寫得最好的領域模型，也無法在令人滿意的時間內處理請求，這是沒有用的。這就是為什麼實體大小和集合邊界如此重要的原因。

在設計聚合時，您需要知道如何處理它們–多久一次，有多少使用者將嘗試同時使用它們，是否會增加活動週期等等。聚合越小，需要載入和儲存的資料越短，事務也就越短。另一方面，總量越小，一致性邊界就越小，因此需要正確的平衡。

8.富有表現力

面嚮物件語言的類結構是對業務概念進行建模的強大工具。不幸的是，它經常被錯誤地使用。最常見的錯誤是用一個類對許多概念進行建模。為此（通常不自覺地）使用狀態和資料位標誌。

通常，此類可以分為幾個類別，這些類別支援SRP。這裡的一種啟發式方法是研究業務語言並研究我們實體的行為。

9.可測試和測試

領域模型用於解決複雜的問題。複雜的問題意味著需要複雜的業務邏輯來解決。如果您有複雜的解決方案，則必須確保它能夠正確執行，並且不必擔心更改此邏輯。

這是單元測試輸入的地方，這是乾淨的Domain Model的組成部分。乾淨的領域模型是可測試的，應該有一個最大的測試覆蓋因素。這是我們應用程式的核心，我們應始終百分百確保它能夠按預期工作。

10.應該輕鬆編寫

這是以上所有內容的總結。如果每次都編寫域模型程式碼是一個問題-很難更改，理解，測試，使用它-出現問題。你應該怎麼做？

檢視我上面描述的所有要點，看看您的模型不符合什麼條件？也許取決於基礎架構？也許他說的是非商業語言？也許是貧血，封裝不良或無法測試？如果您的模型滿足本文中描述的所有屬性，那麼解決業務問題應該輕鬆而愉快。我向你保證。

所以我有一個問題–今天您是通過編寫業務邏輯來放鬆一下，還是再次碰壁？您的領域模型乾淨嗎？