クエリサービスのあり方について質問です。 現在とあるゲームを開発しており以下のようなディレクトリ構成を取っています。 User ├── Domain ├── Application ├── Infrastructure └── Presentation Score ├── Domain ├── Application ├── Infrastructure └── Presentation スコア一覧画面の構成としては 1. ユーザー名(部分一致)でユーザーを検索する 2. 条件に合致したユーザーが一覧で表示され、その中から一人を選択する 3. そのユーザーのスコア一覧が表示される というものになっています。 上記の1の処理においてユーザーを検索する際に 「年齢が18歳以上、検索表示を許可、ステータスが有効」 という条件が暗黙的に設定されます。 これはスコア一覧画面固有の条件です。 また、検索表示許可はオプションのようなものでありユーザー集約に含まれていません。 この場合 案A Score配下のクエリサービス内にユーザーを絞り込む処理を記載する。 　→Score内のクエリサービスなのにスコアに関係ないクエリが含まれてしまってよいのか 案B User配下のクエリサービス内にユーザーを絞り込む処理を記載する。 　→そのクエリサービスのインターフェースはすでにUser/Applicationにある。スコア用の固有の条件を持つのにここに配置してよいのか。 のどちらがよいのでしょうか。 (あるいはどちらも間違いでしょうか)

書籍購入しました。説明がわかりやすくとてもありがたいです。 QueryServiceの責務について質問があります。 QueryService内にSQL実行以外のデータの持ち方の変換処理を書いていいのでしょうか。 例えばUserというテーブルにログインidカラムと住所カラムがあったとします。 ここで「ログインidがloginから始まり、住所が東京のどこかであるユーザー」を絞り込みたいが、パフォーマンス的に厳しいとします。 そこで - SQLではログインidでのみ絞り込みを行う。 - その結果をもとにSQL外で住所で絞り込みを行う。 という構成にしようと思いました。 この後者の絞り込みはQueryService内で行ってもよいのでしょうか。それともQueryServiceはSQLの実行のみに役割を絞り、住所での絞り込みは呼び出し側(UseCaseなど)で行うべきでしょうか

データ量がかなり膨大、かつ正規化され過ぎているため、様々なテーブルとJOINし、様々なwhere句を使っているリポジトリのメソッドがあります。 このリポジトリのメソッドは以下の課題を持っています。 1.集約に関係しないリポジトリからもインターフェイスを介さず、直接呼ばれている 2.クエリが複雑過ぎて保守出来ない(改修した時の影響が見切れない) 性能要件に抵触したため、リファクタリングすることになりました。 まずは単体テストを書いて、想定できるケースは網羅しました。 この後どのようにリファクタリングを進めるべきでしょうか？ また、どの程度までリファクタリングするのがコスパが良いでしょうか？