DDDは集約ごとのリポジトリを指定しますが、Spring Data JPAを採用するときは、エンティティごとにインタフェースを宣言した場合にのみメリットを活用できます。このインピーダンスのミスマッチをどのように解決できますか？ドメイン駆動型デザインリポジトリとSpringデータ型との間に不一致がありますか？
私は、リポジトリインタフェースを集約リポジトリ内にカプセル化してみることを望んでいます。それはOK解決策なのでしょうか。与えられた例に
：Customer集約ルートであり、各エンティティが独自のリポジトリインターフェースを有することから利益を得ることができるところのエンティティはDemographics、Identification、AssetSummary等のようです。 DDDに違反することなく最良の方法は何ですか？
...が、春データJPAを受け入れたときに、我々はエンティティごとのインターフェイスを宣言するときにのみ、我々はメリットを活用することができます...
間違っていると私はあなたが（フィールからこの印象を得る場所を学びたいです自由にコメントすることができます）。 Springデータリポジトリは、ドメインモデルの設計とまったく同じアプローチを期待しています。ドメインモデルで集約を識別し、それらのリポジトリインタフェースのみを作成します。
私はあなたのドメインモデルにDDDの概念を適用するだけでよいと主張します。集約ルートではないエンティティのリポジトリインタフェースを宣言しないでください。実際には、それらを宣言した場合、基本的に集合体の概念を破ることになります。実際のルートは、他の実体をそれらのために定義されたリポジトリインタフェースを通じて操作することができるため、
この例は、Spring Data exampleに正しく適用されています。その中でOrderは集約ルートであり、LineItemは単なる普通のエンティティです。 Customer（root）とAddress（普通のエンティティ）についても同様です。リポジトリインタフェースは、集約ルートに対してのみ存在します。
実際、この特定の関係は、Spring Data RESTのようなモジュールを最初に動作させる基本原理です。集約ルーツのHTTPリソースのみを公開し、作成された表現内の通常のエンティティを埋め込み、他の集約へのリンクを作成します。
お返事ありがとうございます。この問題は、実体を集合体の一部として持つ可能性を検討しようとしているときに発生しましたが、集合体のルートへのリレーショナル・マッピングを持たない、または必要としません。根、私は間違ってこれを仮定していますか？ –
さらに、私はそのようなカスタムインプラントを持っていなければなりません。上記の私の前提が成立すれば、Spring Dataのメリットを先取りすることができます。 –
別の集合体に含まれていないエンティティは、あまりにも。私は通常、エンティティが集約ルート自体である単一エンティティ集約としてそれらを考えます。そのパターンの重要な部分は、集約に含まれるエンティティは、集約を介して操作される場合を除いて操作されてはならないということです。したがって、すべてのJPAエンティティがその側にSpring Dataリポジトリを取得するわけではありません。 –