关注领域模型有一段时间了，不论是分析阶段的还是设计阶段的。
其实领域模型的概念很早就有了,但是其概念非常容易被人混淆，首先我们要明确一下这个词的语境：
它在软件开发的分析与设计的两个阶段分别代表不同的含义。
在分析阶段，领域模型完全是根据需求和用例得出的产物，关于此时领域模型的概念，可以参考拉尔曼的UML模式与应用这本书（在第一版里面叫做概念模型），里面有一个明确的定义，在分析阶段的领域模型是不考虑程序实现上的问题的,也就是说完全是现实逻辑的体现，只不过也是通过UML的类图将其含义表达出来，这个时候的领域模型图是不包括方法的，只有概念，属性和关联。它的侧重点是分析，通过它去更好的理解系统。不过目前结合国内的项目情况来看，在行业领域内，这方面的积累还不是很多，大部分项目还是停留在大量的需求文档阶段，并没有去积累出精练的领域模型。
而在设计阶段，是以分析阶段的领域模型作为依据，在分析阶段通过用例，需求得到一个真实世界的模型，但是离实际软件开发中的类还是有一定差距的，需要不断细化才能得到软件中的类进一步的提炼成为真正的类，这个类是出现在J2EE框架的领域层， 它也叫做领域模型，目前在网上讨论的最多的，实际上都是指设计阶段的领域模型的实现。而这个时候提到的领域模型与分析阶段是有区别的，某些概念都可能会有变更。在这个阶段，有Eric Evans提出的Domain-Driven Design的理论支撑，有Martin Fowler在企业应用架构模式中的Domain Model做指引，我个人认为DDD当中是更侧重于设计阶段的，通过DDD当中所提供的方法可以很科学的得到领域层的领域模型。这个时候还会是去考虑到如何实现，关注对象之间流转，对象的状态，以及如何持久化，比如利用hibernate,jdo,ejb等技术去进行持久化。
据我目前所了解的情况，在当前J2EE的大部分开发框架下，利用设计阶段的领域模型用来实施的项目也并不多。究其也原因是多方面的，很多帖子里面都讨论过。即使是在hibernate出来已经有几年的今天，很多人还是在针对数据库表结构进行开发，在利用面向对象的语言做着面向过程的事，思想也不是1，2天就能转变过来的。