DDD - 在 Spring Data 中维护单独的域类和实体类

Question

我正在开发一个 Spring Boot 项目，其中有两个单独的包，分别名为

domain

和

persistence

。

domain

包主要包含域类（根据业务需求设计），而

persistence

包包含通过扩展

Spring Data

提供的存储库定义的存储库接口。

我在域类中使用了

Spring Data JPA

注释，并且在定义存储库接口时也直接使用这些类。这里一切都运转良好。

但我遇到的问题是，有人可能会争辩说，域类不需要了解持久性实现，并且域类应该保持干净，而不会受到

Spring Data JPA

注释的污染。这让我觉得我应该使用一组不同的类（比如说具有或多或少属性的实体类）来实现持久性，以便我可以保持域类的干净。但如果我这样做；

1. Spring Data

   存储库将与这些

   Entity Classes

   一起使用，我将无法直接使用基于接口的存储库，因为我始终必须将存储库返回的

   Entity objects

   映射到

   Domain Classes

   。
2. 我相信在某个时候，我也会引入

   DTOs

   ，当我达到这个水平时，将会有太多的映射（

   Entity Classes

   到

   Domain Classes

   ，然后

   Domain Classes

   到

   DTOs

   ）。我个人认为，从长远来看，这种映射将是一种开销。

总结- 我应该单独维护

Domain Model Classes

和

Entity Classes

还是应该将

Domain Model Classes

与

Spring Data JPA

注释和 KISS 一起使用？

Answer 1

我认为将存储库接口与域类分开是一个错误。存储库是域的一部分。它们的实现不是，但您不处理实现，因为它是由 Spring Data（和 JPA）提供的。

您的领域类和实体类是否应该分开，这取决于它们是否有不同的需求。 您可能会遇到这样的场景，您需要对实体类进行建模以适应 JPA 或您使用的任何持久性技术的限制，并且您不想将其泄漏到您的域中。

但是直到你遇到这种情况之前，我认为没有必要将它们分开。

如果您担心实体上的注释，那么认识到注释是一种极其弱的依赖关系可能会有所帮助。即使在类路径上，您也可以使用没有注释的实体。所以从纯粹主义者的角度来看，它们是一种气味，但实际上我仍然必须找到它们有问题的情况。

如果你真的想摆脱它们，你可能需要研究jMolecules，它为 DDD 概念提供与技术无关的注释，然后将其转换为 JPA 注释或任何你想要使用的内容。