domain-driven-design - DDD 中的 DAO、存储库和服务

Question

在阅读了几篇文章之后，我开始了解 DAO 和 Repositories 之间的区别，但我发现自己在尝试理解 Repositories 和 Services 之间的区别时遇到了麻烦。

简而言之，在 OO 范式中:

道 : 包含基本 CRUD operations 的类对于一个实体类。它有必要的代码来获取或检索底层持久存储系统的东西。一般来说，方法接收对象实体作为参数，除了 retrieve使用标识符类型有效的方法。

存储库 :在更高层次的抽象中..通常我读过的是一种放置处理聚合对象(具有子对象的对象)的操作的代码的地方。它使用 DAO s 从数据库中检索对象，最后它以领域“业务”语言公开一个接口(interface)。 (但同样，我认为使用 id 的数据类型是非常有效的)。示例:一个非常简单的addSomething在哪里 something是父对象的子对象，其实例顺便说一句，由存储库作为一个整体进行管理。

服务 : 同样，它处于更高的抽象层次。在我看来，它们是连接两个不共享父子关系的类的好地方，但(在抽象方面)与存储库一样远。示例:方法 transferCash两个之间bank accounts .

所以，这就是我的阅读，但我在这里问上述想法是否正确。或者我应该怎么想。或者让我真正理解所有这些概念的区别的东西。

一些来源:

http://debasishg.blogspot.com.ar/2007/02/domain-driven-design-inject.html

http://warren.mayocchi.com/2006/07/27/repository-or-dao/

http://www.sapiensworks.com/blog/post/2012/11/01/Repository-vs-DAO.aspx

What is the difference between DAO and Repository patterns?

Answer 1

存储库 - 就像你说的 - 一个抽象。它们源自 Martin Fowler 的 Object Query Pattern .存储库和 DTO 都可以通过将持久数据映射到实体对象的等效集合来简化数据库持久性。但是，通过提供对整个 Aggregate Root (AG) 的控制，存储库比 DAO 更粗粒度。经常向客户端隐藏很多内部状态。另一方面，DAO 可以像专用于单个实体对象一样细粒度。对于存储库和 DAO，通常使用 Hibernate或其他对象/关系映射 (ORM) 框架，而不是编写自己的实现。

通常，服务可以驻留在服务层中，并且可以充当功能外观、反腐败层和缓存和事务的协调器。它们通常是进行日志记录的好地方。粗粒度和面向用例的服务，例如Service.updateCustomerAdress()或 Service.sendOrder() .存储库可能过于细粒度，客户端无法使用，例如Customer.add(…) , Order.modify(…) .

存储库和 DAO 具有相同的目的 - 永久保存数据。另一方面，服务应该对持久性一无所知，并且不了解您的数据库。它们通常与域服务、存储库、域核心紧密协作。