領域模型檢視原始碼討論檢視歷史
領域模型是對領域內的概念類或現實世界中對象的可視化表示。又稱概念模型、領域對象模型、分析對象模型。它專注於分析問題領域本身，發掘重要的業務領域概念，並建立業務領域概念之間的關係。[1]
核心元素
業務角色顯示了一個人承擔的一系列職責。業務實體表示使用或產生的可交付工件、資源和事件。業務用例實現顯示了協作的業務角色和業務實體如何執行某個工作流程。使用以下幾種圖來記錄業務用例實現： 圖顯示參與的業務角色和業務實體。活動圖，其中泳道顯示業務角色的職責，而對象流顯示如何在工作流程中使用業務實體。 序列圖描述業務角色和業務主角之間交互的詳細情況，並顯示如何在業務用例執行過程中訪問業務實體。
業務對象模型將結構的概念和行為的概念結合了起來。它是一個紐帶工件，用於對業務關係進行清晰的表述，表述方式與軟件開發人員的思考方式類似，同時仍保留一些純粹的業務內容。將我們所知道的有關業務的信息按照對象、屬性和職責進行了合併。
它探索業務領域知識的本質，所採用的方式使我們能夠從對業務問題的思考轉變到對軟件應用程序的思考上來。它是一種確定需求的方法，使需求能夠為待建信息系統使用，並得到該系統的支持。確定業務對象定義、對象間關係、對象名稱和對象間關係名稱的流程使我們能夠以一種能被業務領域專家理解和驗證的精確方式來表達業務領域知識。
命名
對每個業務角色和實體進行命名，要求名稱能夠表示對象的職責。一個好的名稱通常是名詞或動詞的名詞形式， 每個名稱都必須是唯一的。避免使用發音或拼寫類似的詞以及同義詞作為名稱，可能需要用好幾個單詞來組成一個明確的、無需額外說明的名稱。
對象
當您研究參與業務中不同用例的業務角色和業務實體時，可能會發現某些對象如此相似，以致於實際上是一個類。即使不同的業務用例沒有相同的要求，類是之間也可能相似到足以被視為一個相同現象的程度。如果是這種情況，您應該將相似的類合併在一起。這就產生了一個業務角色或業務實體，它擁有足以滿足不同業務用例要求的關係、屬性和操作。
因此，多個業務用例可以對同一個類有不同的要求。對於業務角色來說，如果有些雇員有能力擔當所描述的一組角色，那麼同樣還要有一些比較靈活可以勝任多個職位的雇員。這會使您的業務更加靈活。
模型
在業務對象模型中，業務角色代表雇員將擔當的角色，而業務實體則代表雇員將處理的對象。一方面，可以使用業務對象模型來確定業務雇員將如何進行交互，以產生業務主角所期望的結果。另一方面，系統用例模型和設計模型指定了業務的信息系統。
業務建模和系統建模解決不同的問題，其抽象程度也不一樣。所以一般而言，信息系統不應該直接出現在業務模型中。
另一方面，雇員作為業務角色來使用信息系統，實現相互之間的通信、與主角的通信以及對業務實體信息進行訪問。所有的鏈接、關聯關係或屬性都有某個潛在的信息系統對其進行支持。
這兩類建模環境有以下關係：
作為特定業務角色的雇員與信息系統的一個系統主角相對應。如果建立的信息系統使該雇員在業務用例中的所有工作都得到一個系統用例的支持，則他最有可能得到最好的支持。 另外，如果業務用例規模大、生存期長或者合併了多個獨立領域中的工作，信息系統用例將可以支持業務角色的操作。 雇員工作的對象（建模為業務實體）常在信息系統中得到表現。在信息系統的對象模型中，這些業務實體作為實體類出現。業務實體之間的關聯關係和聚合關係常常使設計模型中實體類之間產生對應的關聯關係和聚合關係。 因此，系統用例訪問並操作設計模型中的實體類，這些實體類代表由被支持業務用例訪問的業務實體。最後，直接使用業務信息系統的業務主角也成為信息系統的系統主角。 當確定對支持業務的信息系統的需求時，這些關係十分關鍵。
主角
有時候，一個業務的雇員與另一個業務的雇員使用其他業務的信息系統進行聯繫。從建模後業務的角度來看，這個信息系統就是一個業務主角。
示例： 某個軟件開發人員努力去理解他所負責的產品中出現的問題。為了了解問題是否源於他所使用的編程工具，他與供應商的萬維網服務器聯繫，並仔細研究編程工具當前版本中已知問題的列表。通過這種方式，業務角色「軟件開發人員」與業務角色「提供商的萬維網服務器」進行交互。
定位
通常的做法是不在業務對象模型中對信息系統進行明確建模，因為信息系統只是業務角色所使用的工具而已。但當業務的信息系統被客戶直接使用時，這種做法就不合適了。如果這個交互是業務服務的主要部分，您可能會出於商業上重要性的考慮而希望在業務對象模型中將其展示出來。電話銀行業務就是此類信息系統的一個很好的例子。
從業務建模的觀點來看，建議使用以下方法：
將信息系統看做一個和主角交互的完全自動化的業務角色。如果信息系統和任何其他業務角色或業務實體相關，則考慮使用鏈接或關聯關係來說明這種關係。系統可能會向某個業務角色通知其進度，或者使用與某個業務實體相關的信息。 簡單地說明業務角色，同時列出代表業務對象模型中信息系統的服務。在信息系統模型中對信息系統和其環境的所有細節和特徵進行建模。引入一個命名約定，這樣可以容易地在業務角色中確定那些完全自動化的業務角色，例如，一個前綴或後綴，如「自動<業務角色名稱>」或「<業務角色名稱>（IT 系統）」。您甚至可以使用一個特殊的圖標來定義構造型。
特徵
總的來看，業務角色和業務實體執行業務用例中描述的所有活動，絕不多一點，也絕不少一點。業務對象模型有效、全面地對組織進行了展示。
設計步驟
領域模型設計是需求分析的關鍵步驟。它幫助用戶及需求分析人員建立業務概念，確定用戶業務的問題域，系統涉及的業務範圍等等。
領域模型設計的步驟為：
1. 從業務描述中提取名詞；
2. 從提取出來的名詞中總結業務實體，區分名詞中的屬性、角色、實體、實例，形成問題域中操作實體的集合；
3. 從業務實體集合中抽象業務模型，建立問題域的概念（例如在前面的例子中，我們把容易變質的水果稱之為「短期保持水果」，當然也可以是其它說法，只要能跟用戶達成共識即可）；
4. 用UML提供的方法和圖例進行領域模型設計、確定模型之間的關係；簡單來說，就是domain object只有屬性的getter/setter方法，沒有任何業務邏輯。