最近在javaEye上看到有关Domain Driving Model Design的激烈讨论，让我对DOMAIN MODEL的理解更深刻了不少，趁现在意犹未尽之际，结合我在项目中的实际经验将讨论中的一些结论摘录并总结出来：

首先引用说明一下Domain Model 的定义：

Domain Model ： An object model of the domain that incorporates both behavior and data.

Domain Model 分两种：

1  Simple Domain Model (Active Record)

它的特点是POJO和TABLE STRUCTURE一一对应，建模基于数据库设计。Hibernate走的就是这个路子，说它贫血，意思就是指它只有data，没有behavior。(但我们实际可以通过HBM文件的定义和映射，在PO中适当的加入一些基本的业务逻辑的。)

在这种模式下，POJO自己的CRUD操作都应该放在自己的类里面。其他复杂的业务逻辑会放到外面的Service layer。

2  Rich Domain Model (Data Mapper)

它的特点是POJO和TABLE STRUCTURE并不一一对应，建模天马行空，完全取决于业务逻辑。domain object和table之间的mapping，由Data Mapper完成，domain object不用管数据表是何等结构，甚至不用管Data Mapper怎么操作。

1.识别某种业务行为的一个很确定的原则：

       domain logic只应该和这一个domain object的实例状态(并非“持久”状态)有关，而不应该和一批domain object的状态有关.

进一步的说：主要看logic是否只和这个object(注：指自身)的状态有关，如果只和这个object(注：指自身)有关，就是domain logic；如果logic是和一批domain object(注：指同类型的实体)的状态有关，就不是domain logic，而是business logic。

2.Domain Model 与 Hibernate PO 的区别：

领域模型的代码实现需要用一组互相协作的类来完成，每一个或者一组类承担这个领域模型的某个特征。而Hibernate的实体类只不过是其中的一组类，它承担的职责就是保持领域模型的状态的。

3.基于Domain Model 分析与设计的方法规则：

应该由领域模型来驱动你的软件内在规则，由需求驱动你的软件外在交互.

最后，我想补充的是：根据目前的O/R Mapping技术，我们在实际项目开发中，能真正做到 富领域模型 还不现实(因为我们还要考虑诸如性能、目前O/R持久化特性等等问题)，更何况，我们的MODEL DATA最终需要被持久化，因此，我比较反对在DOMAIN MODEL 中直接通过任何方式做任何持久化操作，因为这会让你所设计的MODEL无法独立化，难以单元测试，并且与加入了一些外界无关的东西，这不符合对象的本质(对象本身是不能持久化的)。虽然我们做不到完整意义上的Domain Driving Model Development，但我们可以在项目实际开发中因为性能、结构简化等等上面得到补偿，这已经值得欣慰了。