9/30

データベース(QueryService)にビジネスロジックも持たさざるを得ない時(不雑なビジネスロジックでクエリに変化を持たせないといけない時)に解決する方法はございますでしょうか?

具体的には、ユーザー同士がメッセージのやり取りが可能なSNSアプリケーションでの、友達申請できる相手を検索する際に、検索できる対象をユーザーのランクやあらゆるパラメータで制御したいのですが、条件が複雑になっています。
そのため、DomainServiceからQueryServiceを呼び出す(InterfaceをDIして呼び出しています)際に、QueryService側でビジネスロジックの知識が必要になってしまいます。

QueryService側でドメインに依存しない汎用的な考え方を持たせても良いのですが、将来的な変更に弱くなってしまうため、他の方法を検討しています。

お手数ですが、アドバイス頂けますと助かります!

クエリサービスを使う上で突き当たる、非常に重要な課題ですね。 個人的な意見としては、クエリサービスの実装クラスからドメイン知識(ビジネスロジック)を「完全に」なくすのは難しいと考えています。なので、完全になくすことを目指すことではなく、 ①変更容易性を高めるにはどれくらいの知識をもたせるかを検討する ②あとは更新系処理との結合テストをしっかり実施する というアプローチが現実的かと思っています。 今回の検索できる対象のユーザーの件であれば、 クエリサービスの実装クラスで付与する検索条件のうち、 実装クラスないで暗黙的に付与する条件と、引数での指定を表現する物をうまく切り分けて、 あとは更新系処理と合わせた結合テストで動作をカバーする、という地道な形になるのかな・・と思います。 あまり根本解決にならなくて申し訳ありませんが、どうしても複雑なクエリをしようとすると避けられないかなとは思います。