Spring Data 和 DDD - 与持久性无关的域模型答案

【问题标题】：Spring Data and DDD - domain model agnostic of persistenceSpring Data 和 DDD - 与持久性无关的域模型
【发布时间】：2017-11-21 14:30:19
【问题描述】：

您好，具有独立的持久性模型和与持久性无关的域模型是一种常见的模式。我想了解 Spring Data 中如何解决这种模式。

我想象的方式是，如果我们在没有 spring 数据的情况下使用常规 hibernate，我们将拥有可以与域对象一起使用的存储库，这些域对象将在内部映射到 ORM 模型，然后将触发持久性。

如何使用 Spring Data 实现这一点，如果无法实现，可以使用哪些替代机制以使我们拥有与持久性无关的域模型？谢谢。

【问题讨论】：

我没有使用过 spring 数据，但据我所见，它与你为 hibernate 所做的并没有太大不同，spring 数据主要为你的存储库提供了实现, 避免样板代码，除了你将使用 spring 数据注释来注释你的域对象，基于你使用的 spring 数据项目，如 jpa 或 mongodb 等，并使用存储库来持久化。

【解决方案1】：

Spring Data 可以帮助您完成 95% 的工作，但它确实做出了一些妥协。

Spring Data 提供独立于底层持久性技术的存储库。您可以知道，因为它们包含在 Spring Data Commons 基础模块中，所有其他模块都构建在上面。一个例子是CrudRepository。所以基本的 crud 操作都涵盖了。

此外，查询派生不会泄露有关持久性存储的信息。

由于您所做的只是指定这些接口，您几乎可以得到您想要的，因为 Spring Data 正在创建实际的实现。

但这是有局限性的。

您的实体通常需要注释。这些取决于商店。许多人认为这是一个可以接受的折衷方案，因为注释实际上并不包含依赖于存储的代码，他们只是说“嘿，如果你碰巧将它与 <persistence technology x> 一起使用，请按以下方式映射它......”。
更复杂的查询通常通过在存储库方法上添加@Query 注释来实现。这些是依赖于持久存储的。如果您不喜欢它，您可以随时在单独的类中提供自定义实现，让您的接口持久化技术再次不可知。
由于延迟加载和脏检查，某些技术（例如 JPA）的存储特定行为会通过它们的工作方式泄漏到您的应用程序中。

如果你想 100% 与存储无关，我想除了滚动你自己的持久性之外别无他法，可能通过将你的域模型复制到传输对象中并使用 Spring Data 持久化那些。

但这会为开发人员以及运行时的 JVM 带来大量工作，从而带来一些人为的好处。

【讨论】：

最近，我在数据网格计算的上下文和 Web 应用程序的上下文中使用了相同的富域对象。我有 2 个存储库，一个以数据网格为中心，一个以休眠为中心。拥有不可知的域对象是一个优势。它允许以一种简单的便携方式将功能从一个上下文移动到另一个上下文。我会稍微质疑“人为利益”的说法:)
@AlexanderPetrov 使用域模型上的注释不可能做到这一点？

【解决方案2】：

在结合 REST、Hazelcast、JPA 等技术时，我发现用 Hibernate 注释模型是过度的，然后将 DataSerializeable 放在顶部，然后可能通过标记一些 JSon 属性在 REST 上下文中重用它。

为了去除一些依赖关系，一种方法是使用 ORM.xml 并实现自定义 Hazelcast 序列化器。这样，您的最终模型将不依赖于 Hibernate 或 Hazelcast。

替代 iis 使用一些映射器并添加第二层域对象。正如 Jens 已经说过的那样，会有与此相关的开销。

【讨论】：