问题
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?
回答1:
…, 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.
来源：https://stackoverflow.com/questions/38538775/is-there-a-mismatch-between-domain-driven-design-repositories-and-spring-data-on