使用 JPA 实体作为域实体的洋葱架构

Question

我一直在努力选择将 JPA 实体作为单独的类而不是域实体在单个有界上下文中使用。我曾面临以下选择

为聚合根/聚合..etc 使用分离的域类和域存储库来包装 Spring JPA 存储库并使用转换器来映射 JPA 实体 仅具有所需数据的域实体

• 延迟加载即将被放弃，除非映射器/转换器在域存储库中处理此问题，但这是矫枉过正。

• 保存对象时，可能存在相关的聚合根（一对多关系），后来在复杂的逻辑中，我必须非常注意域实体的状态才能将其传递给域存储库，或者用所有相关数据填充它或简单地映射它（转换器中的另一种方法）而不使用关系数据（级联不适用于 JPA 持久化）

• 大量重复的代码可以避免这种情况，即使是非常简单的用例

或者使用 JPA 实体作为我的域实体，到目前为止有多个这样的示例/意见

https://github.com/citerus/dddsample-core/tree/Spring_Annotations_Autowire

http://www.javamagazine.mozaicreader.com/MayJune2018/Twitter#&pageSet=50&page=0

Should JPA entities and DDD entities be the same classes?

DDD, domain entities/VO and JPA

How to implement DDD using Spring Crud/Jpa Repository

另一方面，也有这样的意见

Is it a good practice to use JPA entities as domain models?

我的问题，从长远来看，来自经验

• 什么会花费更多的精力和时间？
• 这两种方法都可以作为实践接受吗？
• 两者的优缺点是什么？

Answer 1

什么会花费更多的精力和时间？

解耦几乎总是如此。这是权衡！

这两种方法都可以作为实践接受吗？

是的。我看到这两种方法都有很多相互矛盾的意见，但实际上，它们只是意见。两者都适用并且成本。

两者的优缺点是什么？

使用 JPA 实体作为域实体方法确实 1- 从概念上减少了时间成本。 2- 还允许您使用延迟加载与关系，避免在应用程序服务中使用更多代码，如果您不遵循通过 id 引用其他聚合，这也是基于意见的，但确实需要 JPA 的延迟加载。

在我看来，这种方法的一个缺点是单元测试。单元测试不应该依赖于启动容器、数据库等。应该纯粹测试业务逻辑。但是对于这样的框架来说，这并不是最佳的可能。例如，请参阅此答案

JPA Entity must be unit tested and how?

使用 JPA 作为基础架构中的独立实体和包装存储库将使单元测试更容易模拟数据并轻松地测试纯域（业务规则）。它将与以前的专业人士相反，花费您映射工作和时间，映射的重复代码过多，包装存储库..等。它带来了关心域实体状态的头痛（这应该是专业的），因为将空值映射到 JPA 实体会影响到持久源的关系映射，您真的应该关心 用于您的域实体的状态。

ORM 的自动延迟加载也不会轻易使用和完成。要么

1- 您将对其他聚合的引用作为聚合根中的成员（打破聚合 ID 引用规则）并在映射器中处理它

2- 您从存储库中只需要聚合根的数据，其他聚合的 ID 作为参考成员。这是通过存储库实现中定义良好的查询来完成的，因此，这是大量的编写和自定义查询。避免使用默认的返回完整的 JPA 实体和准备好的延迟加载相关引用。