domain-driven-design - 存储库实现是我的域的一部分吗？存储库应该有 SQL 查询吗？

Question

存储库实现是我的域模型的一部分，还是我应该只将它们抽象为我的域的一部分？
我应该将 SQL 查询放在我的存储库中，还是将它们放在另一个模式中并作为我的存储库的依赖项传递？
谢谢
更新


更新 2
请看一下:http://leocavalcante.github.io/patterns/2014/07/11/repository-pattern-and-database-schema.html

Answer 1

如果您使用六边形、洋葱或端口和适配器样式架构，那么通常的做法是将存储库接口(interface)放在域模型中，将存储库实现放在持久层/适配器中。然后，您将使用 IoC 容器将它们连接起来，并将持久层的引用添加到域模型。这允许您在持久层中使用域模型实体和值对象，但也可以通过 IoC 访问域模型中的存储库。

你把你的 SQL 放在哪里取决于你，这不是 DDD 的事情，但它可能属于你的存储库。标准做法是使用存储过程或使用 ORM(如 Entity Framework 或 NHibernate)的 LINQ 样式查询。在后一种情况下，查询将存在于存储库中。

好的做法是让您的存储库接受域实体(即用于创建/更新)并返回域实体(即用于查询)。 ORM 生成的任何自动生成的实体通常会被您的存储库隐藏。这似乎会抵消您从 ORM 中获得的许多“优点”(例如延迟加载和双向导航属性)，但这些东西通常是良好 DDD 和特别好的对象/实体设计的障碍.

额外细节

存储库模式的目标是“像列表一样”以隐藏持久性细节。因此，设计存储库的目标是使其成为一个简单的集合，可以在其中添加、删除和更改项目。在幕后，您的存储库可以(应该)知道它存储数据的位置，即 SQL 数据库、平面文件、XML 文件等。

在 DDD 中，您最好希望每个聚合根有一个存储库。例如持久化单个 Customer聚合根(聚合根可以是单个实体，也可以是由其他实体或值对象组成的实体)可能会导致写入 4 个单独的表。