存储库类应该进入哪一层？域还是基础设施？
问问题
4111 次
4 回答
22
存储库接口是域的一部分。接口的实际实现应该是基础设施的一部分。
于 2010-08-23T07:00:23.190 回答
4
存储库实现类以及单独的接口（如果存在）应该进入域层。
原因在于分层架构中要遵循的基本规则：较低层不能依赖于较高层。
如果我们接受这个规则（否则它不是分层架构），那么将存储库实现放入基础设施层将使其依赖于领域层，因此违反了分层的基本规则。
例如，当我们创建一个新的领域实体时，我们把它放在领域层；并且由于存储库（其接口和实现）必须不可避免地依赖于域实体，这意味着存储库也必须进入域层。否则，只要在域层中添加/删除/修改域实体，我们就会更改基础设施层。
其他问题，例如保持域层“干净”和独立于持久性细节，可以而且应该通过使用来自域层内部实现的适当基础设施服务来实现。例如，在 Java 中，我们可以使用 JPA 用很少的代码来实现存储库，并且不需要 SQL/JDBC 或数据库特定的代码（使用 JPA 实现存储库是否真的是一个好主意是另一个讨论；无论如何，JPA 实体将无论如何都要使用 JPA 注释）。
于 2015-04-09T20:56:54.780 回答
2
存储库类的实现应该位于基础设施层。存储库接口应该在服务层中。
域层应该对存储库一无所知。DDD 的战略模式表明领域层应该始终与概念模型同步。这意味着域层应该将众所周知的域进程转换为代码，反之亦然。领域流程是您的领域专家应该了解的。领域专家对存储库一无所知。
另一种思考方式。假设我们将存储库或存储库接口放入域层。即，现在我们在域层代码中有存储库概念。此外，领域层应该与领域的概念模型同步。所以，让我们问问自己，概念模型中存储库的表示是什么。正确答案是概念模型中没有存储库。因此，存储库不能位于域层中。
总而言之，我仍然遇到在领域层中有存储库的项目，项目的工程师仍然称其为 DDD 实践。我认为这里的问题是人们并没有过多关注位于 DDD 核心的战略模式，而只是玩弄可以稍微简化编码工作的战术模式。
于 2021-04-20T12:42:01.790 回答
0
我想这取决于你将如何依赖他们。
问题是 - 您是否允许自己使用域内部的存储库？
如果是这样 - 那么你被迫把它们放进去。
我自己喜欢把它们放在域之外。所以 - 某事物的典型生命周期如下所示 =>
UI => 控制器 => 从 repo 检索聚合根 => 通过聚合根调用逻辑 => 如果创建了新的聚合根，则将其添加到 repo。
有时，控制器调用应用程序服务，除了检索根目录并在其上调用函数之外，它还会做一些额外的事情。但想法是一样的——域对持久性一无所知。
虽然（如我所见）将 repos 放入域（或至少是它们的抽象）中没有错，但它使您的域更加意识到持久性。有时这可以解决问题，但通常 - 这肯定会使您的域更加复杂。
使用对你来说更自然的东西，随时准备改变你的方式。
于 2010-08-17T08:58:26.817 回答