1.引言

我們還是先來拆詞理解，領域模型可以拆為“領域”和“模型”二詞。

• 領域：按照我們之前的文章的理解，DDD中的領域是指軟體系統要解決的問題，如我們的辦公裝置公眾號線上商城就是為了解決電商問題，對應的就是電商領域。

• 模型：百度百科解釋為對於某個實際問題或客觀事物、規律進行抽象後的一種形式化表達方式。如戶型圖就是實際房屋結構的模型。

把兩個詞結合起來，我們給領域模型下個定義：領域模型是對我們軟體系統中要解決問題的抽象表達。

這個理解還是很生澀，沒關係，容我娓娓道來。

2.領域模型的來歷和作用

我們知道，軟體開發過程主要包括：需求分析、概要設計、詳細設計、編碼、測試、軟體交付、驗收、維護。其實簡單來說就是分析、設計和實現。

而傳統的軟體開發方式中，系統分析、設計和實現三個階段完全脫節，最後開發出來的軟體不能很好的滿足業務需求，在未來也不能很好的適應需求變化進行功能演進。

那在DDD中是如何做到呢，下面我們就從以下幾個問題來分析說明。

1. 怎樣確保最終的軟體設計能滿足客戶需求且適應變化？
   那就要保證系統分析、設計和實現不脫節。

2. 那如何做到不脫節呢？
   如果按照我的理解，那就需要有某一個東西能貫穿整個開發流程，來銜接分析、設計和實現三個階段。

3. 那這個東西是什麼呢？
   聰明如你，是的，就是我們今天的主題——領域模型。

4. 那領域模型是如何做到的呢？
   在分析階段，所有的參與人員（領域專家、設計人員、開發人員等）對業務進行需求分析，通過大家的不斷交流討論，提取出業務規則和流程中的關鍵詞彙和概念形成通用語言，進而發現領域概念，隨著大家對領域的認識不斷深入，通用語言的詞彙也會不斷豐富和精準，從而確保了業務需求的正確表達。
   在設計階段，以通用語言為交流基礎，將發掘的領域概念進行領域模型設計，以面向物件的思想抽象出實體，確定實體所對應的方法和屬性，以及實體之間的關係。然後將這些實體和實體之間的關係以某種形式展現出來，形成領域模型。
   在實現階段，開發人員根據確立的領域模型進行程式碼實現，做到程式碼與模型的繫結，從而實現了設計和實現階段的銜接。
   通過這樣一種方式，我們實現了語言、模型、程式碼三者緊密繫結，確保開發出來的軟體來準確反應需求並能適應變化。

通過上面對領域模型的來歷和作用的介紹，我們對領域模型就有了一個大致的印象。

3.案例分析

按照上面的理解，領域模型無非就是綜合了系統分析和設計的產物，而這個產物我們正好可以通過UML來展示，下面我們就結合辦公裝置微信公眾號線上商城案例，簡單對銷售子域進行領域模型設計。

從該銷售子域的UML類圖中，我們可以看出它包含了銷售子域涉及到相關實體以及實體之間的關係。只要看到這個類圖，我們就知道它涉及的相關概念和流程。所以說上面這張UML類圖是銷售子域的領域模型也不為過。

4.總結

領域反應的是我們業務上需要解決的問題，模型是我們針對該問題提出的解決方案。
綜合來說，領域模型就是用來描述我們正在解決的問題和提出的解決方案。

領域模型按照我個人的理解，就是將業務中涉及到的概念以面向物件的思想進行抽象，抽象出實體物件，確定實體所對應的方法和屬性，以及實體之間的關係。然後將這些實體和實體之間的關係以某種形式（比如UML、圖形、程式碼、文字描述等）展現出來。

以上只是領域模型理論上的理解，但領域模型的設計（領域建模）卻是另一個複雜的話題，擇日再聊。

參考資料：
領域模型，你真的理解的了嗎？
DDD領域驅動設計基本理論知識總結
What is the Domain Model in Domain Driven Design? | Culttt

相關文章

原文地址：http://www.cnblogs.com/sheng-jie/p/6931622.html

.NET社群新聞，深度好文，微信中搜索dotNET跨平臺或掃描二維碼關注