关于领域模型、DAO的疑问？？

       1）事务脚本。在《POJOS in action》中，DAO模式出现在事务脚本中（我看到最早的关于DAO的文字在《J2EE核心模式》中）。通过那个事务脚本的例子及《POEAA》，我对事务脚本的理解是，事务脚本是由DTO、DAO和TransactionScript组成。和领域模型不同的地方在于，DTO不是整个模型的核心，它只是一个值对象而不包含业务逻辑；业务逻辑是在TransactionScript中，但其中的业务逻辑是不可重用的，因为TransactionScript是面向上层的应用而没有抽象出业务逻辑；DAO就是我们在各种书中能看到的那个样子。

       2）领域模型。我觉得领域模型由四部分组成（也可以看作两部分，如果那些辅助类不算一部分的话），核心的就是领域对象，它除了具有值对象特征外还包含业务逻辑；这个业务逻辑可分为两种，一种是和外部资源有关的逻辑（如持久化逻辑），一种是领域的领域逻辑（比如什么税率之类）。在java中很难在领域对象中包含持久化逻辑，所以就分化出独立的实现持久化逻辑实现类，所以我觉得富领域对象并不意味着就要包含持久化逻辑，事实上多数持久化逻辑是静态的（如果在领域对象中存在FindAllAccount（）这样的方法我觉得很奇怪），最重要的是我觉得领域对象应该是可重用的，所以不应该包含了持久化逻辑。在《POJOS in action》中，关于领域模型的例子中它是使用Repository这个词而不是DAO来表示持久化逻辑，在《DDD》和《POEEA》中也没有使用DAO这个词表示持久化逻辑，所以我很想知道DAO这个概念是不是应该出现在领域模型中？但让我觉得有意思的是，《POJOS in action》中的Repository是继承自Spring的HibernateDAOSupport。而与外部资源无关的逻辑大多以辅助类的方式（通过策略等模式？）实现，但这些逻辑本身的调用是在领域对象中，这样领域对象就拥有了行为特征。最后就是service了，这是面向应用的一层，我糊涂的地方在于Facade，还是在《POJOS in action》中，它的Facade竟然和Repository一个级别！！再理一下头绪，按我的理解，持久化逻辑是领域对象的辅助类，这主要是实现技术上的折衷，它和那些策略类是一个级别的，甚至不能按一层来算。

       说了这么多，其实我对领域模型还是蒙蒙东东的，由于精力有限，论坛中关于领域模型的帖子也没有全看。还有《POJOS in action》、《DDD》、《POEAA》，看得我有些头晕，MF似乎在《POEAA》中也没有给出如何构建包含持久化的领域模型，至于他的什么三种模型是在哪篇文章中提到的呢？哪位明白DDD的不妨说说自己的想法，最好能具体到实现，到底该如何理解DDD并利用当前常用的框架中运用DDD呢？

我看到大家都在讨论如何将持久化注入到领域对象中，使得领域对象具有持久化能力，但这真的需要吗？独立存在DAO作为辅助类不是很好吗？我觉得领域对象需要的就是与持久化无关的领域逻辑，它们只对service开放，就像DAO那样，而向上开放的接口只有service。

DDD在本论坛中算是老生常谈了，很多年前robbin就总结过好几次，不过也只能是他个人的观点罢了，这个问题还是仁者见仁智者见智了，很难形成统一意见的，甚至PoEEA的MF本人也未必能说清楚并使人信服。

我的理解和做法可以综合表述为以下几点：
1、所谓业务层应是向外部开发的唯一接口这点没问题，但业务层不仅仅是XxxService，Domain本身也应当是业务层的一部分；
2、不要强迫自己认为持久化与业务无关，这会让你苦恼，很多时候持久化本身就是业务，例如最简单的只有CRUD需求的功能点，如果不把它们当作业务的话，可能该功能就没有业务存在了；
3、让DAO来负责持久化存取，目的是把持久化操作部分的代码分离出来，但并不代表让DAO来负责持久化的业务，应该是让Domain或者Service通过调用DAO来实现持久化操作；
4、让Domain负责该Domain自身的逻辑，包括insert/update/delete，并且负责其与其他Domain关系的维护，通过调用DAO来实现；
5、让Service负责Domain的获取如getById什么的，这时候其充当的是Manager的角色，并且负责跨Domain业务逻辑的实现，调用Domain或DAO功能来实现，这也是为了更好的进行Transaction控制；