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

ユーザーのapplication層(ユースケース層)にクエリサービス(のIF)を定義してクエリサービスのapplicationService(責務を明確にするためにユースケースクラスとするのをお勧めしています)から呼ぶ、でいいと思います。 まず、クエリサービスは集約をまたいで検索はOKです。むしろクエリサービスを定義したい目的の大半はそれです。 で、同じユースケース層であるユースケースクラスからクエリサービス(のIF)を呼ぶのは問題ありません。ここで大事なのは、「ユーザー/スコアのコードか」よりも「どのレイヤーか」を意識する方が大切です。ドメイン層もユースケース層も、同じレイヤーのオブジェクト同士は自由に参照してOKです。一方、層に関しては依存の向きを厳密にする必要があります。その方が保守性を保つために大きく貢献するためです。なので同じユースケース層であれば、ユーザー、スコアを跨いで問題ないのです？ そのため、パッケージとしてもまずはレイヤー(domain,usecaseなど)でわけ、その下にユーザー、スコアとそれぞれ分ける方がお勧めです。レイヤーをより意識しやすいためです。