ドメイン オブジェクトがあり、それが有効であることを確認するなど、そのドメイン オブジェクトの責任の中心となる便利なことをしたい場合、この検証を実行するために、関連するオブジェクトの状態にアクセスする必要がある場合があります。
ドメイン オブジェクトがリポジトリまたはデータ アクセス レイヤーを呼び出す必要がないようにするにはどうすればよいですか? パフォーマンスのために、遅延読み込みを使用しても常にコレクション関係をたどることができるとは限らず、ドメイン オブジェクトでクエリを実行したいことがよくあります。リポジトリの実装をドメインに依存性注入することはできますが、実際には純粋ではなく、テストが複雑になります。
私は常に物事を緩和し、DI を使用してドメインからリポジトリへのアクセスを許可してきました。複雑なアプリケーションで「純粋な」ドメイン層を使用する方法の明確な例は見たことがありません.
オブジェクトが値オブジェクトである場合、それは不変であり、構築中に検証される必要があります。
オブジェクトがルート集約であり、それが有効かどうかを判断するのにそれ自体の状態で十分である場合は、集約をカスケードする検証メソッドをオブジェクトに追加できます。
最後に、それがあなたの主な関心事だと思います.1つが有効であることを確認するために複数の関連オブジェクト(同じ集合体にない)にアクセスする必要がある場合は、特定の検証サービスでこのロジックを確実にデポートする必要があります.
サービスとリポジトリをエンティティに注入することは、最良の選択ではないと本当に思います。専用サービスを作成する方が適切に思えますが、それによってドメイン オブジェクトが貧弱になる理由がわかりません。
つまり、サービスやリポジトリに依存せずにオブジェクトの状態を検証できる場合は、集約ルート レベルでオブジェクトに処理させます。サービスやリポジトリにクエリを実行する必要がある場合、または他のエンティティが必要な場合は、このロジックをオブジェクトの外に移動することを強く検討してください。
ほんの数時間前に同様の質問に答えました。回答には、インフラ技術関連のものへの依存関係でモデルを汚すことなく、ロジックと動作でモデルを充実させようとするときに使用するいくつかのガイダンスが含まれています。 現実世界のロジックを DDD ドメイン層に入れるのに問題がある
回答は、他の有用なリソースにもリンクしています。
幸運を祈ります。お気軽に私にメールするか、DDD と貧血モデルの回避について質問してください。これは、人々がさまざまな方法でこれを解決する傾向がある興味深いトピックです。