关于rich domain object的一点总结

晚上在论坛上瞎逛，翻到 了一个讨论rich domain object的帖子，最后还是那句话，怎么合适就怎么来，管它是poor还是rich。企业应用总是离不开和数据库打交道，那么在domain object中不应该关心持久化问题。所以呢，如果使用java，dao还是要的。
从[url]http://www.javaresearch.org/article/68086.htm[/url]和[url]http://www.blogjava.net/langds/archive/2005/04/07/2892.html[/url]中，
1.识别某种业务行为的一个很确定的原则：
domain logic只应该和这一个domain object的实例状态(并非“持久”状态)有关，而不应该和一批domain object的状态有关.
进一步的说：主要看logic是否只和这个object(注：指自身)的状态有关，如果只和这个object(注：指自身)有关，就是domain logic；如果logic是和一批domain object(注：指同类型的实体)的状态有关，就不是domain logic，而是business logic。

如果domain logic显示依赖于持久化，那么该业务方法还是移到XXXManager中合适，在XXXManager中再通过dao来执行数据库操作。

2.Domain Model 与 Hibernate PO 的区别：

领域模型的代码实现需要用一组互相协作的类来完成，每一个或者一组类承担这个领域模型的某个特征。而Hibernate的实体类只不过是其中的一组类，它承担的职责就是保持领域模型的状态的。
3.基于Domain Model 分析与设计的方法规则：
应该由领域模型来驱动你的软件内在规则，由需求驱动你的软件外在交互.

总结（使用java的情况下）：
1.service层：处理业务请求，一个service提供一个确定的服务。一个service可能需要和多个domain object 和domain object manager来协作完成一项任务。
2.dao层：提供持久化操作。
3.domain object manager:实现不是明确依赖于domain 状态的行为，这些行为同样应该是只跟该domain object相关联。有时候其相当于一个提供单一domain object相关操作的service。
4.domain object:包含该domain object的状态和行为