谈一谈贫血的Domain Logic问题。

看了七彩狼,partech等人的讨论， 我的首贴的观点中关于将持久化功赋予DM基本是错误的。 我也逐渐这么认为！
我认为七彩狼的几个回帖还是很能说服我的！ 
基本上可以这么总结（全部是个人的思考，如果有错误，请批评！）：
partech 七彩狼 Robbin的观点是一致的，只不过他们之间的表述有些不一致。
虽然Robbin认为POJO是可以放入业务逻辑。 这个跟partech是一致的，但是他们在具体表述怎么实现复杂的业务逻辑时出现了表述的不一致。 Robbin认为这是Service的功能，而partech对这个Service的理解是它应该作为一个Service Facade，供应用层直接调用，Service应该调用具体的DM，DM代表实现各种复杂业务逻辑的模型，具有属于自身的业务逻辑的POJO也属于这层。只不过对于一个复杂的业务逻辑可能需要一个专门的领域对象调用协作的其他不同领域对象来完成。
说到底，他们的观点是基本一致的，只不过表达上出现了偏差。


对于一个基于内存模型的领域模型，数据持久的行为与领域模型是毫无关联的，然而一个具体的银行开户并不会简单得涉及到new Account（）的这么一个行为，它会牵涉到多个对象的建立，以及执行相应的逻辑。将这整个 业务流程放在其中的某个对象均是不妥当的，这样的结果必然出现一个专么负责完成开户所有流程以及建立完成开户后完整的内存模型 的领域对象，很多人对于这么一个对象赋予不同的名词，一些人给他命名为Service，一些人给他命名为控制类，一些人给他命名为Act等等。 但是不同的人对于这么对象却有不同的理解，一些人认为这不属于DM，一些人认为这属于DM，一些人认为这是Transaction Script， 至于相应的数据持久化不应该出现在Domain model中，
至于说要赋予领域模型复杂查询的功能，这种说法确实很值得推敲.赋予领域模型复杂查询功能有可能是实现某些业务流程必要的步骤,那么就 给领域模型这么一个DAO接口!

我赞成用一个Service 调用一个领域对象的某个方法，完成一个具体业务的逻辑，然后进行调用具体的DAO进行数据持久化。


谢谢大家的热情！ 因为我这么一个胡思乱想的帖子引发这么激烈的争论 ，这是意想不到赫！  嘿嘿，不过感觉自己的思路已经越来越清晰了！ 谢谢大家！