如何使用Spring Crud / Jpa存储库实现DDD [英] How to implement DDD using Spring Crud/Jpa Repository
问题描述
我想通过使用Spring实现DDD来创建应用。假设我有一个业务实体Customer和一个接口CustomerRepository。
I want to create an app by implementing DDD using Spring. Let's say I have a business entity Customer and an interface CustomerRepository.
因为spring提供了 CrudRepository 和 JpaRepository 默认执行基本的CRUD操作和其他操作，例如finder方法，我想使用它们。因此我的界面变为
Since spring provides CrudRepository and JpaRepository to perform basic CRUD operations and other operations like finder methods by default I want to use them. So my interface becomes
@Repository
public interface CustomerRepository extends JpaRepository<Customer, Long>{
}
但是根据DDD，接口应该在域层中，实现应该在域中基础设施层。
But according to DDD, interfaces should be in domain layer and the implementation should be in Infrastructure layer.
现在我的问题是，CustomerRepository属于哪一层？
Now my question is, which layer the CustomerRepository belongs to?
推荐答案
简短的回答：，尽管它应该是域层中对基础结构的任何依赖关系，但为了亲吻，您可以这样做。如果您想成为DDD的纯粹主义者，请定义 CustomerRepository 接口，并在基础结构中定义一个实现这两个接口的实现。
Short answer: although it should be any dependencies to Infrastructure in the Domain layer, for the sake of KISS, you may to do so. If you want to be a DDD purist, you define a CustomerRepository interface AND an implementation in the Infrastructure that implements both the interfaces.
冗长而无聊的答案：通常，域不应关心或了解基础架构，因为它不应与其他层（基础结构，应用程序，表示或您所使用的任何体系结构）具有依赖性正在使用）。遵循此规则将导致更简洁的体系结构。
Long and boring answer: In general, the Domain should not care or know about infrastructure, as in, it should not have dependencies to other layers (Infrastructure, Application, Presentation or whatever architecture you are using). Following this rule leads to a cleaner architecture.
特别是，域不应该关心持久性，它应该在内存中运行时表现得如此。从域的角度来看，实体会发生变化，仅此而已，就不需要持久性。
In particular, the domain should not care about the persistence, it should behave as it runs in memory. From the Domain point's of view, the Entities mutate and that's all, no persistence is needed.
域代码的写入端实际上不需要持久性。当聚合执行命令时，它们已经完全加载。在执行命令之后，聚合仅返回更改或新状态。汇总不会自己保留更改。它们是纯净的，没有可观察到的副作用。
The Write side of the Domain code doesn't in fact need persistence. When the Aggregates execute commands, they are already fully loaded. And after the command is executed, the Aggregates just return the changes or the new state. The Aggregates don't persist the changes themselves. They are pure, with no observable side effects.
我们的架构师需要持久性，因为我们需要确保数据在两次重启之间持久存在并且可以运行相同的数据
We, the architects, need persistence because we need to ensure that the data persist between restarts and that we can run the same code on multiple machines on the same time.
但是，还需要另一个域代码，尤其是域的读取和响应侧（Sagas / Process）。经理）。域的这些组件需要查询和过滤域实体。 Readmodels需要将实体返回给调用者，而Sagas / Process经理需要正确地确定向其发送命令的正确聚合。
There is however, another need that the Domain code, in particular the Read and the Reactive side of the Domain (Sagas/Process managers). These components of the Domain need to query and filter the Domain Entities. The Readmodels need to return the Entities to the caller and the Sagas/Process managers need to correctly identify the right Aggregates to whom to send the Commands.
解决方案是定义仅在域层的接口，并在基础结构中具有实现。域以这种方式拥有接口，因此，根据依赖关系反转原理，它不会
The solution is to define only the Interfaces in the Domain layer and to have implementations in the Infrastructure. In this way the Domain owns the Interface so, according to the Dependency Inversion Principle, it does not depend on the Infrastructure.
在您的情况下，尽管域层取决于Spring框架基础架构部分中的某些内容，但 > something 仅仅是一个接口。这仍然取决于JPA，因为您的域将使用它不拥有的方法，但在这种情况下，KISS可能更为重要。
In your case, although the Domain layer depends on something from the Infrastructure part of the Spring Framework, that something is only an Interface. It is still a depency to JPA because your domain will use methods that it doesn't own but KISS could more important in this case.
另一种方法是使用在实现此接口和JpaRepository接口的基础架构中的实现，定义一个不扩展JpaRepository的接口。 >
哪种解决方案取决于您：更多的代码重复，但更少的依赖性或更少的代码重复，以及对JPA的更多依赖性。
Which solution depends on you: more code duplication but less dependency or less code duplication and more dependency to JPA.
这篇关于如何使用Spring Crud / Jpa存储库实现DDD的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
