DDD - 服务层和存储库之间的重复

Question

我曾开发过几个尝试遵守 DDD 原则的应用程序，我注意到我们最终会遇到服务层和存储库之间存在重复的情况，感觉就像代码异味。

对于服务层中的大多数操作，它似乎直接映射到 CRUD 操作、GetAll、GetById、Create、Delete 等。架构的流程在以下几行之内：我有一个 controller 调用 Service layer 调用 Repository 调用 ORM 与 Backend 对话> ..

因此，例如 GetAll 将同时存在于 SL 和存储库中。现在，如果我们有一个更改/业务要求 GetAll 应该忽略某些项目，我应该怎么做，我应该在存储库中忽略这些，还是应该进入服务层的业务逻辑？如果我们只是有一个服务层直接调用 ORM，生活会不会更轻松？

总结：我知道服务层可以抽象一些业务逻辑，但是在大多数情况下，它处理简单的 CRUD 操作时，摆脱存储库不是更容易吗？但是，如果 SL also 包含一些业务逻辑复杂的方法，这些方法应该通过存储库吗？从良好的设计角度来看，我应该支持一致性并始终通过存储库还是保持简单并且仅在存储库不是简单的一对一映射到 CRUD 操作时才使用存储库。

PS：我意识到似乎有类似的问题，但没有找到任何令人满意的答案

Answer 1

在大多数情况下 - 它处理简单的 CRUD 操作，不是吗？ 更容易摆脱存储库

恕我直言，我不会说要摆脱存储库。我会说，如果你在做 CRUD，你根本不需要 DDD。如果您阅读 Fowler 的企业模式或 Evans，他们都说 DDD 仅在您拥有非常复杂的域逻辑时才有用。 CRUD 并不复杂，因此不需要 DDD。

您所描述的是代码异味。但我不认为这是 DDD 的气味。您只是看到了一段过度设计的代码。

Answer 2

也许“Finder 模式”（不知道这是否正确）可以解决您的问题。根据CQS（Command-Query-Separation）原则，（IMO，）查询操作根本不是“业务逻辑”。我们可以在基础设施层写一些特定的“查找器”来执行各种查询，让所有非查询操作（业务逻辑）留在服务层，然后在客户端我们将查找器视为服务。
对不起我的语言:-(。

Answer 3

我注意到我们最终会遇到重复的情况 在服务层和感觉像代码的存储库之间 闻起来。

这不是代码异味，因为它们做不同的事情。

您应该记住，域或应用程序服务与存储库实现位于不同的层。层的存在是有原因的——不同层中的对象没有相同的职责，也不会与相同的邻居对话。存储库实现与对象的持久性方式紧密耦合。他们可能会生成 SQL 语句并与关系数据库对话，他们可能会与您的 ORM 对话......重要的是他们知道您的对象的持久化方式，而应用程序服务并非如此.

如果你的服务层直接调用 ORM，它真的会做两件大事，打破单一职责原则。将您的 ORM 更改为另一个或不同的持久性方式也会更加困难。

因此，例如 GetAll 将同时存在于 SL 和存储库中。现在，如果 我们有一个 GetAll 应该忽略的变更/业务需求 某些项目，我应该怎么做，我应该忽略这些 存储库，或者那是应该进入服务的业务逻辑 层？

如果 GetAll() 忽略某些项目，我强烈建议在服务和存储库中重命名它以反映这一点，例如：GetAllAllowedToUser()、GetAllBut...()。因此，该方法的合同将是明确的，您将避免对它应该返回的内容产生误解。另外，您将能够保留原始的真正 GetAll() 方法，该方法仍有一些用处。

Answer 4

Dtryon +1，也：

现在，如果我们有一个变更/业务需求，GetAll 应该忽略某些项目

没有直接关系，我知道你只是用它作为例子，但我已经看到了这个确切的东西。请不要以调用 GetAll 的方法结束，但不能获得全部。保留 GetAll，拥有 GetAll，然后拥有 GetAllLive，或 GetAllAvailable 或类似的东西，按它说的做