領域模型是對領域內的概念類或現實世界中物件的視覺化表示。又稱概念模型、領域物件模型、分析物件模型。它專注於分析問題領域本身，發掘重要的業務領域概念，並建立業務領域概念之間的關係。
（1）概念類分類表
就是事先分好類，然後由分析人員在需求資訊中尋找相應類別的候選物件進行確定和歸納，形成概念類。
顧客向系統提起查詢請求。
系統根據請求為顧客提供cd的推薦列表。
顧客在推薦列表中選定乙個cd，然後要求檢視詳細的資訊。
系統為顧客提供選定cd的詳細資訊。
顧客購買選定的cd。
顧客離開。
(2)名詞分析
從文字表述中提取有關的名詞和名詞短語，作為候選物件，然後對候選物件經行分析，初步確定感念類。
如下（加粗的為候選物件）：
顧客向系統提起查詢請求。
系統根據請求為顧客提供cd的推薦列表。
顧客在推薦列表中選定乙個cd，然後要求檢視詳細的資訊。
系統為顧客提供選定cd的詳細資訊。
顧客購買選定的cd。
顧客離開。
（3）行為分析
行為分析是從需求描述中搜尋及物動詞，我們都知道及物動詞前後的是主動物件和被動物件，把他們作為候選物件。
圖二:
第7行和第15行是「無」，因為使用者的個人行為和電梯系統無關，不屬於系統行為。
主要是看候選類是否具有狀態（類的屬性值）和行為特徵（對類物件的操作）。
候選類既有狀態又有行為，那麼它應該是對立存在的概念類。例如候選類~「商品」和「**」，商品同時具有狀態和行為，而**只有狀態，顧客會查詢商品資訊，裡面就包含**，而顧客不會憑空查詢**。**應該作為商品的屬性存在。
如果候選類只有行為沒有狀態說明出現了紕漏。
圖一的修正
概念列中的詳細資訊不能作為概念類，因為它只有狀態沒有行為。
圖二的修正
摒棄的物件：
使用者：系統之外的物件，提供資料輸入。
第i,j層：只有狀態沒有行為。
兩個方面著手：
一：分析問題域內的靜態結構關係，發現靜態類的關係。
二：分析概念類的協作。
保證類之間寫作所必需的可見性。如果兩個物件例項需要實現互相之間的寫作，那麼至少它們中的乙個物件例項要持有另乙個現象例項的鏈結(如：主鍵和外來鍵)。在保證可見性的情況下寫作才能成為可能。因此，如果兩個類存在寫作關係，那麼它們就應該具有能夠保證可見性的管理。為保證類之間寫作而建立的關聯時必要關聯，是物件模型必不可少的部分。
適當使用問題域內的關聯，增強領域模型的可理解性。有些類之間不需要互相協作（如：包含），但是它們的物件例項在問題域內存在某些重要而且固定的關係。這些關係式問題域特性的必要部分，因此需要為這些關係建立關聯以增強領域模型的可理解性。對問題域內關係的識別要適可而止，因為問題域內的關係式複雜而繁多的，它們建立太多的關聯不僅不能有效地表示領域模型，反而會是的領域模型變得混亂。
不要再關聯的識別上花費太多的時間。識別概念模擬識別關聯更加重要。一方面是因為遺漏的概念模擬較難以發現，而遺漏的關聯則很容易在後續的處理階段得到建立。另一方面是因為常常有些深層次的關聯發現起來非常費時，但帶來的好處不大。
避免顯示冗餘和匯出的關聯。發現關聯後使用合適的動詞短語為關聯命名，描述每個關聯端的角色和多重性。關聯名稱通常按照自上至下、至左至右的方式白哦大概念類之間的關係。在分析階段，一般不會描述關聯的方向和關聯端的可見性。不過在非常必要的情況下（如存在重要的約束或者某些類有特殊要求），也可以描述關聯的方向而活關聯端的可見性。
用圖一來舉例:
需要協作的概念類~1.顧客（發起）購買（選擇）cd。
問題域內的聯絡~1.查詢請求（產生）cd推薦列表。2.cd推薦列表（包括）cd。
圖：
富領域模型和貧血領域模型
貧血領域模型乙個明顯的特徵是 它僅僅是看上去和領域模型一樣，都是物件，都以領域空間中定 義的名詞命名，這些物件通過實際領域模型中豐富的關係和結構相互關聯。但是觀察模型所持有的 業務邏輯時會發現，貧血模型中除了大量 getter 和 setter，幾乎沒有其他業務邏輯。當然，在使用貧血領域模型時，那些...
領域模型（一）
每個軟體程式是為了執行使用者的某項活動，或是滿足使用者的某種需求。這些使用者應用軟體的問題區域就是軟體的領域。為了建立真正能為使用者活動所用的軟體，開發團隊必須運用一整套與這些活動有關的知識體系。所需的知識廣度可能令人望而生畏，龐大而複雜的資訊也可能超乎想象。模型正是解決此類資訊超載問題的工具。模型...
領域模型（二）
model driven design 模型驅動設計 利用模型來為應用程式解決問題。團隊成員通過ubiquitous language 通用語言 交流進行知識消化，以便有效建模，而model driven design繫結模型與實現，以此為出發點做出的軟體產品才能在完全理解核心領域的基礎上提供豐富的...