如何使用 Spring Crud/Jpa Repository 实现 DDD

Question

我想通过使用 Spring 实现 DDD 创建一个应用程序。假设我有一个业务实体 Customer 和一个接口 CustomerRepository。

由于 spring 提供 CrudRepository 和 JpaRepository 来执行基本的 CRUD 操作和其他操作，如默认的 finder 方法，我想使用它们。于是我的界面就变成了

 @Repository
public interface CustomerRepository extends JpaRepository<Customer, Long>{

}

但是根据 DDD，接口应该在领域层，实现应该在基础设施层。

现在我的问题是，CustomerRepository 属于哪一层？

Answer 1

简短回答：虽然它应该是域层中基础设施的任何依赖项，但为了KISS，您可以这样做。如果您想成为一个 DDD 纯粹主义者，您可以定义一个 CustomerRepository 接口和一个在实现这两个接口的基础架构中的实现。

冗长而无聊的答案： 通常，域不应该关心或了解基础架构，例如，它不应该依赖于其他层（基础架构、应用程序、演示或任何您所在的架构）使用）。遵循此规则会导致更清洁的架构。

特别是，域不应该关心持久性，它应该像在内存中运行一样运行。从域的角度来看，实体会发生变异，仅此而已，不需要持久性。

域代码的写入端实际上不需要持久性。当聚合执行命令时，它们已经完全加载。并且在命令执行后，聚合只返回更改或新状态。聚合不会保留更改本身。它们是纯净的，没有明显的副作用。

我们，架构师，需要持久性，因为我们需要确保数据在重启之间保持不变，并且我们可以同时在多台机器上运行相同的代码。

然而，域代码还有另一个需要，特别是域的读取和响应端（Sagas/流程管理器）。域的这些组件需要查询和过滤域实体。 Readmodels 需要将实体返回给调用者，而 Sagas/Process 管理器需要正确识别向其发送命令的正确聚合。

解决方案是仅在域层中定义接口并在基础架构中实现。通过这种方式，域拥有接口，因此根据Dependency Inversion Principle，它不依赖于基础架构。

在您的情况下，尽管域层依赖于 Spring 框架的基础设施部分的 something，但 something 只是一个接口。它仍然依赖于 JPA，因为您的域将使用它不拥有的方法，但在这种情况下 KISS 可能更重要。

替代方法是定义一个不扩展 JpaRepository 的接口，并在实现此接口和 JpaRepository 接口的基础架构中实现。

哪种解决方案取决于您：更多的代码重复但更少的依赖或更少的代码重复和更多的对 JPA 的依赖。