フィルタリングロジックは、リポジトリまたはサービス内にある必要がありますか？

私は次のことを考えています。エンティティを検索するためのフィルタリング機能が必要なシステムを構築しているとします。たとえば、エンティティをリストするテーブルにフィルタリングを適用して何かを見つけたり、それを使用してフィルタリングされたセットに関するレポートを生成したりすることができます。

重要なのは、フィルタリングロジックをどこかに置く必要があるということです。これを行う1つの悪い方法は、必要に応じてフィルタリングロジックを複製することです。私はそれを一度やったことがあり、それはひどい考えです。

一方、Filter(FilteringOptions filteringOptions)フィルタリング操作を実行してエンティティのフィルタリングされたリストを返すように設計されたようなメソッドがあるはずです。

今、私見、フィルタリングロジックは一種のビジネスロジックです。ビジネスエキスパートは、フィルタリングがどのように行われるか、何がどのようにフィルタリングされるかを知っている人です。そのため、フィルタリングロジックはドメインレイヤーに配置する必要があります。

これを行うための2つのオプションが見つかりました。その特定のエンティティに対応するリポジトリにフィルタリングメソッドを埋め込むか、またはEntityNameSearchServiceリポジトリを使用してフィルタリングを実行するようなドメインサービスを作成します。

どちらがより良い方法であるか私はまだ混乱しています。では、DDDを適切に使用しようとしている場合、このフィルタリングロジックはどこにあるべきでしょうか。リポジトリまたは別のサービスで？

私は次のことを考えています。エンティティを検索するためのフィルタリング機能が必要なシステムを構築しているとします。たとえば、エンティティをリストするテーブルにフィルタリングを適用して何かを見つけたり、それを使用してフィルタリングされたセットに関するレポートを生成したりすることができます。

この点に注意してください。フィルタリングの使用例は、書き込みではなく読み取りを中心としています。これは通常のパターンです。通常、書き込みはドメイン内の特定の集約ルートにアドレス指定されます。

読み取りを実行している場合は、実際には集計を気にする必要はありません。実際に何かを変更しようとしているわけではないため、ビジネスインバリアントの適用については気にしません。あなただけの状態を気にします。

つまり、ドメインモデルを完全にバイパスすることが理にかなっている可能性があります。

考えるだけの何か。

今、私見、フィルタリングロジックは一種のビジネスロジックです。ビジネスエキスパートは、フィルタリングがどのように行われるか、何がどのようにフィルタリングされるかを知っている人です。そのため、フィルタリングロジックはドメインレイヤーに配置する必要があります。

はいといいえ。フィルターを説明するためにユビキタス言語を利用しています。したがって、あなたは間違いなくドメイン語彙を使用しています。

しかし、実際にレコードブックを変更していない限り、「振る舞い」はありません。したがって、不変条件を心配する必要はありません。

一方、フィルター操作を実行し、エンティティーのフィルターされたリストを返すように設計されたFilter（FilteringOptions filteringOptions）のようなメソッドがあるはずです。

あなたは「仕様」という考えにとても近いです。これは基本的に、リポジトリが任意の基準に一致するアーティファクトを識別するために使用できる述語です。

注意すべきトラップがいくつかあります。 グレッグ・ヤングは少し前にそれらについて触れましたが、ここで要約します。

まず、コレクションに対して述語を実行する抽象化はO（N）です。特に永続ストアがインデックス作成に優れている場合は、おそらくもっと良いものが欲しくなるでしょう。永続化コンポーネントは、それを実装固有の制約に変換できるようにする必要があります（例：仕様を取得し、それを準備済みステートメントのwhere句に変換します）。

第2に、インターフェースは、永続コンポーネントによって提供されるコントラクトを文書化する手段です。「暗黙的に明示する」-本当に必要なものを説明すると、インターフェースはデータストアにとって重要な特性について何かを教えてくれます。ストアが適しています。

（もちろん、そのインターフェースの実装は、メソッドの引数から仕様を作成し、それを転送するアダプターにすぎない場合があります。これで問題ありません。実際の要件を取得しました）。