DDD 为每个聚合指定存储库，但是在采用 Spring Data JPA 时，我们只有在为每个实体声明接口时才能利用这些好处。这种阻抗不匹配如何解决？
我希望尝试封装在聚合存储库中的存储库接口，这是一个好的解决方案还是更好的解决方案？
举个例子：Customer 是聚合根，实体如Demographics、Identification、AssetSummary 等，每个实体都可以从拥有自己的存储库接口中受益。在不违反 DDD 的情况下，最好的方法是什么？
【问题讨论】：
标签： spring-data domain-driven-design spring-data-jpa ddd-repositories
...，但是当采用 Spring Data JPA 时，我们只有在为每个实体声明接口时才能利用这些好处...
这是错误的，我想了解您从哪里获得这种印象（请随时发表评论）。 Spring Data 存储库期望您的域模型设计采用完全相同的方法：您识别域模型中的聚合，并仅为这些聚合创建存储库接口。
我认为您需要做的就是将 DDD 概念应用于您的域模型。简单地不要为不是聚合根的实体声明存储库接口。事实上，如果你声明了这些，你基本上打破了聚合的概念，因为实际的根不能再控制业务约束，因为其他实体可以通过为它们定义的存储库接口进行操作，即不使用聚合根。
在Spring Data example 中找到正确应用的示例。其中，Order 是聚合根，LineItem 只是一个普通实体。这同样适用于Customer（根）和Address（普通实体）。存储库接口仅存在于聚合根。
事实上，这种特殊的关系是让 Spring Data REST 等模块首先工作的基本原则。它只公开聚合根的 HTTP 资源，将普通实体嵌入到创建的表示中，并创建到其他聚合的链接。
【讨论】：