存储库应该放在哪一层？
存储库类应该放在哪一层？域还是基础设施？
Which layer should the repository classes go in? Domain or Infrastructure?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
存储库类应该放在哪一层？域还是基础设施？
Which layer should the repository classes go in? Domain or Infrastructure?
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（4）
存储库接口是域的一部分。接口的实际实现应该是基础设施的一部分。
The repository interfaces are part of the domain. The actual implementation of the interfaces should be part of the infrastructure.
我想这取决于你将如何依赖他们。
问题是 - 您是否允许自己使用域内部的存储库？
如果是这样 - 那么你被迫将它们放入。
我自己喜欢将它们放在域之外。所以 - 事物的典型生命周期看起来像这样 =>
用户界面 =>控制器=>从存储库检索聚合根 =>通过聚合根调用逻辑=>如果创建了新的聚合根，请将其添加到存储库中。
有时，控制器调用应用程序服务，除了检索根并调用其上的函数之外，还执行一些其他操作。但想法是相同的——域对持久性一无所知。
虽然（据我所知）将存储库放入域（或至少是它们的抽象）中没有任何问题，但它使您的域更加了解持久性。有时这可以解决问题，但一般来说 - 这肯定会让您的领域变得更加复杂。
使用对您来说更自然的方式，并随时准备改变您的方式。
I guess that depends how You are going to rely on them.
Question is - are You going to allow Yourself to use repositories from inside of domain?
If so - then You are forced to put them in.
I myself like to put them outside of domain. So - typical life cycle of something looks like this =>
UI => Controller => retrieve aggregate root from repo => call logic through aggregate root => if new aggregate root created, add it to repo.
Sometimes controller calls application service that does some additional stuff besides just retrieving root and calling function on it. But idea is same - domain knows nothing about persistence.
While (as I see it) there's nothing wrong with putting repos in domain (or at least abstractions of them), it makes Your domain more aware of persistence. Sometimes that can solve problems, but generally - that will definitely make Your domain more complex.
Use what seems more natural for You and be ready to switch Your ways any time.
存储库实现类以及单独的接口（如果存在）应该进入域层。
原因是分层架构中要遵循的基本规则：较低层不得依赖于较高层。
如果我们接受这个规则（否则它不是分层架构），那么将存储库实现放入基础设施层将使其依赖于领域层，因此违反了分层的基本规则。
例如，当我们创建一个新的领域实体时，我们将其放入领域层；由于存储库（其接口和实现）必然依赖于领域实体，这意味着存储库也必须进入领域层。否则，每当在域层中添加/删除/修改域实体时，我们都会更改基础设施层。
其他问题，例如保持域层“干净”并独立于持久性细节，可以而且应该通过使用域层内部实现中的适当基础设施服务来实现。例如，在 Java 中，我们可以使用 JPA 来实现存储库，只需很少的代码，并且不需要 SQL/JDBC 或特定于数据库的代码（使用 JPA 实现存储库是否真的是一个好主意是另一个讨论；无论如何，JPA 实体都会无论如何都要使用 JPA 注释）。
参考文献：维基百科，
MSDN
Repository implementation classes, together with separate interfaces (if they exist) should go into the domain layer.
The reason is given by the fundamental rule to be followed in a layered architecture: a lower layer must not depend on a higher layer.
If we accept this rule (otherwise it's not a layered architecture), then putting repository implementations into the infrastructure layer would make it dependant on the domain layer, therefore violating the fundamental rule of layering.
For example, when we create a new domain entity, we put it in the domain layer; and since a repository (both its interface and its implementation) must inevitably depend on the domain entity, it means the repository must also go into the domain layer. Otherwise, we would be changing the infrastructure layer whenever a domain entity was added/removed/modified in the domain layer.
Other concerns, such as keeping the domain layer "clean" and independent of persistence details, can and should be achieved by using the appropriate infrastructure services from the implementations inside the domain layer. For example, in Java we can use JPA to implement repositories with very little code, and no SQL/JDBC or database-specific code (whether it's really a good idea to implement repositories with JPA is another discussion; in any case, JPA entities will make use of JPA annotations anyway).
References: Wikipedia,
MSDN
存储库类实现应位于基础设施层中。存储库接口应该位于服务层。
域层应该对存储库一无所知。 DDD 的战略模式指出，领域层应始终与概念模型同步。这意味着领域层应该将众所周知的领域流程转换为代码，反之亦然。领域流程是您的领域专家应该熟悉的内容。领域专家对存储库一无所知。
另一种思考方式。假设我们将存储库或存储库的接口放入域层中。即现在我们在域层代码中拥有存储库概念。此外，领域层应该与领域的概念模型同步。那么，让我们问自己，存储库在概念模型中的表示是什么。正确答案是概念模型中没有存储库。因此，存储库不能位于域层中。
总而言之，我仍然遇到在领域层拥有存储库的项目，并且项目工程师仍然将其称为 DDD 实践。我认为这里的问题是人们不太关注 DDD 核心的战略模式，而只是玩弄战术模式，这可能会稍微简化编码工作。
Repository classes implementations should be situated in the Infrastructural Layer. Repository interfaces should be in the Service Layer.
Domain Layer should know nothing about the repositories. Strategic patterns of DDD state that Domain Layer should always be in sync with conceptual model. That means that Domain Layer should translate well known domain processes to code and vice versa. And domain process is what your domain experts should know well. And domain experts know nothing about repositories.
Another way to think about it. Let us suppose we put repositories or the interfaces of repositories into a Domain Layer. I.e. now we have the repository concept in Domain Layer code. Also, the Domain Layer should be in sync with the conceptual model of domain. So, let us ask ourselves what is the representation of repository in the conceptual model. The correct answer is that there is no repository in the conceptual model. Hence, repository can not be in Domain Layer.
All said, I still come across projects which have repositories in the Domain Layer and engineers on the projects still call it a DDD practice. I assume the problem here is that people do not pay a lot of attention to strategic patterns which lie at the heart of DDD, but just play around with the tactical patterns which may simplify coding efforts a bit.