域驱动设计 – DDD中的DAO,存储库和服务

在阅读了几篇文章之后，我开始了解DAO和存储库之间的区别，但是我发现自己很难理解存储库和服务之间的区别。

简而言之，在OO范式中：

> DAO：包含一个实体类的基本CRUD操作的类。它具有获取或检索底层持久存储系统的必要代码。一般来说，方法接收对象实体作为参数，除了在使用标识符类型有效的检索方法中。
>存储库：在更高层次的抽象..通常我已经阅读是一种处理聚合对象(具有子对象的对象)的操作的代码。它使用DAO从数据库中检索对象，最后它以“业务”域名公开了一个接口。 (但同样，我认为使用ids的数据类型是非常有效的)。示例：一个非常简单的addSomething，其中某些东西是父实例的子对象，其实例btw由Repository作为一个整体进行管理。
>服务：再次，它处于更高的抽象层次。对于我的谦虚观点，他们是连接两个不共享父子关系的类的好地方，但是与存储库一样远(在抽象术语中)。示例：两个银行账户之间的方法transferCash。

所以，这是我的读物，但是我在这里询问上面的想法是对还是不对。或者我应该怎么想或者让我真正了解所有这些概念的区别。

一些来源：

> 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?

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

通常，服务可以驻留在服务层中，并且可以作为功能外观，反腐层和缓存和协调器的协调器。交易。他们往往是进行伐木的好地方。服务粗粒度和面向用户，例如。 Service.updateCustomerAdress()或Service.sendOrder()。存储库对于客户来说可能太细了，例如。 Customer.add(…)，Order.modify(…)。

存储库和DAO具有相同的目的 – 永久保存数据。另一方面，服务应该是不了解持久性的，不了解你的数据库。他们通常与域服务，存储库，域核心紧密结合。