在網上搜尋領域模型，有大量的文章。一種是**於最初的傳統軟體開發過程，一種**於領域驅動設計（ddd）。在傳統軟體開發中，軟體設計師通常使用uml語言進行系統建模，裡面也在強調領域模型的重要性，這兩者很容易混淆。我給大家找到了一些資料，先來看看傳統軟體開發中，領域模型是什麼。
領域模型是什麼？
理論派觀點：
實戰派觀點：
領域模型作用？
理論派領域模型是一種特殊業務模型，作用是：
實戰派領域模型作用：
業務模型作用：
領域模型與業務模型的區別?
理論派實戰派業務模型是在軟體開發過程中業務建模階段產生，領域模型是在分析階段產生。
業務模型是系統需求人員理解客戶公司業務的產物，下一階段需求將以業務模型輸入得到系統需求。
領域模型是系統分析人員分析如何滿足系統功能性需求的產物。下一階段軟體設計將以領域模型為輸入。
「實戰派」舉例說明：
當接到專案，需要做乙個酒店預訂系統，首先先入業務建模，了解客戶公司酒店管理的相關 業務，這就會產出業務模型，此時業務模型裡除了酒店預訂這個業務環節還包括其他與酒店預訂同層次的業務環節。
接下來將視線聚焦到酒店預訂，改進已有流程得到酒店預訂系統需求，也就是系統用例和需求規約。
接下來通過分析系統用例和需求規約，分析如何滿足酒店管理系統功能性需求，從而得到領域模型。
從上面例子描述上看到，「理論派」和「實戰派」的領域模型是兩個範疇的東西，乙個更關注業務，乙個更關注軟體實現。若沒有分清肯定會引起理解混亂。
另一種「領域模型」—領域驅動設計（domain-driven design）
還有一種「領域模型」，它出自於埃里克·埃文斯（eric evans） 的領域驅動設計，簡稱ddd，ddd是一套綜合系統分析和設計的物件導向建模方法，所以要明確區分傳統軟體開發中的領域模型和領域驅動設計中的「領域模型「。失血模型、貧血模型、充血模型這些類概念都屬於ddd範疇的「領域模型」。
兩種領域模型的區別
本文中「領域模型」都代表領域驅動設計中的領域模型。
解決的核心問題不同
正如剛剛前面提到的，領域模型是乙個用於分析業務的分析模型，在實際專案中要解決的核心問題：
而ddd中「領域模型」是綜合分析與設計的模型，要解決的核心問題是：
在傳統的軟體開發流程中，分析（系統需求分析）和設計（系統設計）被劃分為兩個階段，分別對應國家「系統分析師」和「系統設計師」兩種職稱，這種割裂的結果導致，「系統設計師」要基於「系統分析師「需求分析分析的結果做系統設計，然後才能進行編碼，這中間會存在資訊上的丟失或失真，並且實際過程中業務需求會變，這個變化可能是外界環境的變化或者對業務有更深的理解引起，就更容易引起系統設計與專案需求脫節。埃里克·埃文斯（eric evans）提出的ddd思想就是想解決業務與設計被割裂這樣的問題。
領域不同
領域模型是業務分析模型，分析的是系統功能性需求所反映出的核心業務，軟體系統只是實現業務的方式而非業務的一部分（提供iaas服務的公司除外），不會考慮系統設計it領域裡的問題。
而ddd中的「領域模型」是綜合分析和設計的模型，涉及到系統設計，需要思考系統的邊界，故該模型所分析設計的領域是綜合了業務領域和it領域。
以酒店預訂系統為例，其業務描述如下：
以上涉及兩個物件：使用者、會員。
若做業務分析，第一段描述中的「使用者」可能就要考慮，究竟這些「使用者」是遊客呢，還是企業客戶。哪種「使用者」是主要客戶源，如何針對這些「使用者」做針對性的服務，以便更加有力的吸引「使用者」預訂酒店客房。
若要考慮系統設計，那第一段描述中的「使用者」可能就會忽略，即不在系統邊界範圍內。只需要要提供「客房查詢」功能即可。
使用的階段和崗位不同
領域模型是分析業務的分析模型，在實際專案中主要由系統分析師在分析階段中使用。
ddd的「領域模型」是綜合分析、設計的模型，在實際專案中橫跨分析和設計兩個階段，崗位需要具備「系統分析師」和「系統設計師」的綜合能力。
為什麼要區分，不能混淆？
包含的內容不同
領域模型主要內容：
ddd的「領域模型」主要內容：
總結
領域模型分理論派和實戰派，理論派屬於商業範疇不屬於軟體開發範疇，軟體開發過程不用理會理論派，切忌相互混淆。
實戰派認為領域模型是一種分析模型，用於分析理解複雜的業務領域問題，具體到軟體開發過程中，就是在分析階段分析如何滿足系統功能性需求。
同時在軟體開發範疇還有來自於ddd的「領域模型」，這是一種綜合分析與設計一體的模型，不僅僅注重需求分析與還更關注系統設計、系統需求的銜接，它要求設計出系統與需求要有較好的一致性，所以針對合理的需求變化也更具有良好的擴充套件性。
這樣一對比，領域驅動設計中的「領域模型「就好理解的多了，它的領域模型關注的不僅是業務，還更關注怎麼把業務和設計如何有機的結合起來。
好的，以上就是今天的分享。下次來聊聊傳統的領域模型與領域驅動設計中的「領域模型「都是如何設計系統的，他們分別都有什麼優缺點。
DDD 領域驅動設計 領域模型中的使用者設計
驗證 根據 userid 判斷此使用者是否擁有部落格。許可權 根據當前 loginname，判斷此使用者是否擁有審核許可權。public int userid public string userloginname public string userdisplayname public strin...
DDD領域模型閱讀思考
ddd領域模型閱讀思考 常見軟體設計模式注重資料庫和資料表模型，把錶捋出來來以後，彷彿 流程就出來了，但這個只是多個儲存模型，儲存資料的流程，這樣是能完成儲存資料的功能，但是是很底層的設計思路，思路固化以後，會容易寫出麵條串似的業務流程 沒有確定 領域邊界，不是至頂向下，而是從底向上的思考，這樣的 ...
DDD領域驅動設計 充血模型 貧血領域模型
最早廣泛應用源於ejb2，最強盛時期則是由spring創造，把 分離到不同的物件中 貧血領域模型是乙個存在已久的反模式，它不是個好東西。它完全和物件導向設計背道而馳。物件導向設計主張將資料和行為繫結在一起，而貧血領域模型則更像是一種面向過程設計。貧血領域模型的根本問題在於，它引入了領域模型設計的所有...