關注領域模型有一段時間了，不論是分析階段的還是設計階段的。
其實領域模型的概念很早就有了,但是其概念非常容易被人混淆，首先我們要明確一下這個詞的語境：
它在軟件開發的分析與設計的兩個階段分別代表不同的含義。
在分析階段，領域模型完全是根據需求和用例得出的產物，關于此時領域模型的概念，可以參考拉爾曼的UML模式與應用這本書（在第一版里面叫做概念模型），里面有一個明確的定義，在分析階段的領域模型是不考慮程序實現上的問題的,也就是說完全是現實邏輯的體現，只不過也是通過UML的類圖將其含義表達出來，這個時候的領域模型圖是不包括方法的，只有概念，屬性和關聯。它的側重點是分析，通過它去更好的理解系統。不過目前結合國內的項目情況來看，在行業領域內，這方面的積累還不是很多，大部分項目還是停留在大量的需求文檔階段，并沒有去積累出精練的領域模型。
而在設計階段，是以分析階段的領域模型作為依據，在分析階段通過用例，需求得到一個真實世界的模型，但是離實際軟件開發中的類還是有一定差距的，需要不斷細化才能得到軟件中的類進一步的提煉成為真正的類，這個類是出現在J2EE框架的領域層， 它也叫做領域模型，目前在網上討論的最多的，實際上都是指設計階段的領域模型的實現。而這個時候提到的領域模型與分析階段是有區別的，某些概念都可能會有變更。在這個階段，有Eric Evans提出的Domain-Driven Design的理論支撐，有Martin Fowler在企業應用架構模式中的Domain Model做指引，我個人認為DDD當中是更側重于設計階段的，通過DDD當中所提供的方法可以很科學的得到領域層的領域模型。這個時候還會是去考慮到如何實現，關注對象之間流轉，對象的狀態，以及如何持久化，比如利用hibernate,jdo,ejb等技術去進行持久化。
據我目前所了解的情況，在當前J2EE的大部分開發框架下，利用設計階段的領域模型用來實施的項目也并不多。究其也原因是多方面的，很多帖子里面都討論過。即使是在hibernate出來已經有幾年的今天，很多人還是在針對數據庫表結構進行開發，在利用面向對象的語言做著面向過程的事，思想也不是1，2天就能轉變過來的。