引用自http://www.jdon.com/jivejdon/forum/messageList.shtml?thread=32093&count=15&start=30

什么是DAO，Repository?

在Repository情况下，DAO其实是多余的，Repository可以完全替代DAO。

以JiveJdon3打个比喻： ForumMessage中包含Forum和Forumhread，这三者是一致性，必须保持不变，在这个系统中必须同进同出，你通过Repository获得一个ForumMessage时，它必须将Forum和Forumhread从各自数据表中读取后，嵌入ForumMessage中，形成一个完整的一致的ForumMessage。

同理，你对ForumMessage进行修改时，也必须对其内嵌也就是高聚合的子对象Forum和Forumhread进行更新，CRUD都是要这样。在CRUD时，你不能单独对ForumMessage对应的数据表进行操作，这就破坏对象的不变性。

然而DAO则没有这些规定，就是简单的数据访问封装，至于你是以数据库为中心的编程思路，还是以OO为中心，都不管，实际它更多带有数据库思路，所以我也是主张摒弃DAO的。
　　

　　在仓储也包含CRUD操作，这些操作必须包括完整聚合关系，保证不变性，比如帖子和论坛之间就是不变性，汽车和汽车发动机和车身都是不变性的，这些都要在仓储完成，比如保存汽车时，必须对汽车发动机和车身一同做保存，而且必须依赖事务全部锁定，只有一个用户才能操作；查询汽车时，也必须给汽车组装好汽车发动机等，当然这里面涉及工厂模式和Builder模式。

总之，从仓储出来的都是像样的领域模型，仓储中这种主对象和从对象的一致性也可以通过框架，比如JPA/Hibernate实现，不必自己做了。而DAO则和数据表结构有关系，属于数据库派的；而仓储是地道的领域对象派

　DDD的了解

　　所谓的 ＤＤＤ无异于将所有的业务抽象到领域层，所有的都是对象，所有的对象对自己负责，具体实现时，我的思路是这样的：　　首先对业务领域建模，摈弃以往的以数据为中心的思想，首先不考虑哪些需要持久化，尽管根据业务流程进行建模，建模完成后，到了我们考虑哪些数据需要持久化了。从领域对象中找出需要持久化的数据模型，再次审视所有的业务对象的职责，或者通俗的说，把握一个尺度，对于所有与持久化相关的操作，如果是简单的ＣＲＵＤ则放到对应ＤＡＯ中，涉及查询等放到仓储中查询，使用工厂进行对象创建，如对于lay-load之类的问题则可以通过仓储和工厂解决。大颗粒度操作抽象到对应服务中。最后就是再次在更高的层次审视整个模型，必要时使用Ｆａｃａｄｅ　模式，在系统最上方加一层，如果涉及团队或老系统集成，在必要的Context中添加anti-corruption层