域驱动设计存储库和Spring Data存储库之间是否不匹配？ [英] Is there a mismatch between Domain-Driven Design repositories and Spring Data ones?

问题描述

DDD指定每个聚合的存储库，但是当使用Spring Data JPA时，我们只有在声明每个实体的接口时才能利用这些好处。如何解决这种阻抗不匹配的问题？

我希望尝试封装在聚合存储库中的存储库接口，这是好的解决方案还是更好的解决方案？

p>

举个例子：客户是汇总根，实体类似于人口统计，标识， AssetSummary 等，每个实体都可以从拥有自己的存储库接口中受益。最好的方法是什么，而又不违反DDD？

解决方案

…，但是当使用Spring Data JPA时，只有在声明每个实体的接口时，我们才能利用这些好处……

那是错误的，我想了解一下您在哪里得到这种印象来自（随时发表评论）。 Spring Data存储库期望使用与域模型设计完全相同的方法：在域模型中标识聚合，而仅为它们创建存储库接口。

我认为您需要做的就是将DDD概念应用于您的域模型。只是不要为不是聚合根的实体声明存储库接口。实际上，如果声明了这些，则基本上就打破了聚合的概念，因为实际的根不再能控制业务约束，因为可以通过为它们定义的存储库接口来操纵其他实体，即无需使用聚合根。 p>

在此 Spring数据示例。其中， Order 是一个聚合根， LineItem 只是一个普通实体。 客户（根）和地址（普通实体）也是如此。存储库接口仅针对聚合根存在。

事实上，这种特殊的关系是使像Spring Data REST这样的模块首先工作的基本原理。它仅公开用于聚合根的HTTP资源，将普通实体嵌入所创建的表示形式中，并创建指向其他聚合的链接。

DDD specifies repository per aggregate, but when embracing Spring Data JPA, we can leverage the benefits only when we declare interface per entity. How this impedance mismatch can be resolved?

I'm hoping to try out repository interfaces encapsulated within the aggregate repository, is that a OK solution or anything better available?

To given an example: Customer is the aggregate root and entities are like Demographics, Identification, AssetSummary etc. where each entity can benefit from having their own repository interfaces. What is the best way without violating DDD much?

解决方案

…, but when embracing Spring Data JPA, we can leverage the benefits only when we declare interface per entity…

That's wrong and I would like to learn where you get this impression from (feel free to comment). Spring Data repositories are expecting the exactly same approach to your domain model design: you identify aggregates in your domain model and only create repository interfaces for exactly those.

I'd argue that all you need to do is applying the DDD concept to your domain model. Simply don't declare repository interfaces for entities that are not an aggregate root. In fact, if you declared those, you basically break the concept of an aggregate, as the actual root cannot control business constraints anymore as the other entities can be manipulated through the repository interface defined for them, i.e. without using the aggregate root.

Find an example of this applied correctly in this Spring Data example. In it, Order is an aggregate root, LineItem is just an ordinary entity. The same applies to Customer (root) and Address (ordinary entity). Repository interfaces only exist for the aggregate roots.

In fact, that particular relationship is the fundamental principle that makes modules like Spring Data REST working in the first place. It only exposes HTTP resources for aggregate roots, embeds ordinary entities within the representations created and creates links to other aggregates.

这篇关于域驱动设计存储库和Spring Data存储库之间是否不匹配？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！