DDD では、データベースの読み取りと書き込みなどによって、リポジトリを使用して集計のシリアライズとデシリアライズを実行します。こうすることで、集約にはより純粋なビジネス ロジックを含めることができ、ドメイン固有ではない永続化戦略と結合することはありません。
しかし、リポジトリが常に集約に使用されると説明されているのはなぜだろうか。それをすべてのエンティティに使用する動機は同じではありませんか?
(これが、すべての単純なエンティティーがゼロの子を持つ集約ルートと見なされるという事実だけの問題である場合は、このことを私に通知してください。質問は埋もれてしまう可能性があります。)
リポジトリが常に特に集計に使用されると説明されているのはなぜだろうか。それをすべてのエンティティに使用する動機は同じではありませんか?
集計は、アプリケーション層に公開される整合性の境界であるためです。
つまり、はい、リポジトリはデータ ストアから状態のスナップショットを取得し、そこから集計を構成するエンティティと値のグラフを作成する役割を果たします。
リポジトリの API は、一貫性の境界を定義するため、集約ルートのみを公開します。アプリケーションがグラフ内の任意の場所に到達して変更できるようにする代わりに、アプリケーションがルート オブジェクトと排他的に通信するように強制します。この制約が整っていれば、すべての変更がビジネス不変条件を満たしていることを確認するために、1 か所を調べるだけで済みます。
そのため、モデル内のエンティティの種類ごとにリポジトリを開発する必要はありません。アプリケーションがモデルと直接対話することは許可されていないためです。
別の言い方をすれば、集約内のエンティティはプライベートデータ構造です。クライアント コードがエンティティを直接操作することを許可していません。同じ理由で、クライアントが API を通過してポインターを直接操作できるようにするリストを実装していません。
cqrsには、集計以外に使用される「リポジトリ」が表示されます。リポジトリは、モデルの状態のキャッシュされたビューを検索するためにも使用できます。秘訣は、ビューが変更をサポートしていないことです。Evans が説明するアプローチでは、各エンティティには、そのすべての役割を満たす 1 つの表現があります。CQRS では、エンティティはロールごとに異なる表現を持つ場合がありますが、通常、エンティティの変更をサポートするロールは 1 つだけです。