如何通過領域模型把領域邏輯組織起來?

當選擇好開發的方式，選擇好物理程式集的分配方式，但如何把這些商務邏輯組織起來也是一個很大的問題。首先，得搞清楚什麼樣的邏輯屬於領域邏輯，這就一個很大的難題。很多時候，需要花很長時間來判斷某個邏輯是應該歸屬於領域邏輯還是歸屬於基礎設施或是其他。這就對使用領域驅動設計和DDD分層的開發人員提出了很高的要求。但是等您一旦熟悉使用這種方式時，再較為複雜的邏輯，您一樣也可以很輕鬆的解決。

領域模型裡面應該放什麼呢？我自己總結了下面幾點，不過這不是最好的，我也在學習之中。

第一，任何和UI相關的是絕不能放在領域邏輯層的。即包含領域模型邏輯的程式集絕不會依賴UI庫。

第二，涉及到使用某個領域的庫時，就到考慮了。例如做一個GIS的項目，裡面有圖層的概念，裡面可能有圖層的一些配置資訊類，我覺得在領域模型中就需要引用這些圖層類了。因為你也不可能把這些圖層的介面包一層，而在領域模型中避開對這些第三方庫的依賴。那樣的話，代價就太高了。這是可能會出現這種情況，你用的第三方庫的這個核心dll自己本身依賴一些UI庫。我現在也不知道如何處理這種情況比較好。我只能說那個第三方庫不怎麼樣。最終決定還是依賴這個庫，但這就和第一條有矛盾了。沒辦法。

第三，使用者所能理解的邏輯應該放到領域模型中。把使用者不用關係的具體實現放到基礎設施層。例如使用者關係產品的定價不能高於1萬塊。使用者知道學校分布資料是一個向量資料。使用者知道地圖的概念，知道地圖包含幾個圖層。但使用者並不關心你的資料存在哪兒，如何把地圖顯示在案頭上，以及發郵件的具體技術如何?。

理想的情況下，如果是用Donet開發，領域模型程式集應該只依賴DoNet中的幾個最基本的dll。

雖然有一些可以判斷的規則，但是每當遇到具體的情況時，都會有一些特殊的情況需要處理，而且這些特殊情況往往還很多。這就要靠設計人員和開發人員的經驗了。有些邏輯是很模糊的，放到那個層似乎都比較合適。

領域模型即包括實體物件,也包括值對象.實體物件就是在整個系統中唯一存在的一個對象,值對象就是可以共用複用的對象.領域模型中的資訊既包括需要持久化的資訊,也包含一些輔助資訊.總之,領域模型要把客戶需求中出現各種名詞基本上都要定義到.

這樣才能保證完全捕獲到了客戶的需求,並能夠很好的應付使用者需求的變化,

在定義領域模型時，可以使用繼承，多態等特性。一切的定義和實際情況向匹配，至於怎麼把這些實體物件映射到資料庫中，那就是資料持久化層的職責了。有時候，可能會有為了方面資料持久化層合一些基礎設施層可能會稍微修改一下領域模型，以方便其使用，但決不能因為這些原因把領域層修改的‘面目全非’。

這個層是整個系統的核心層。在最初做需求和系統開始開發的時候，最先確定和開工的就是這個模組。