Laravelにおいて、Repositoryパターンは多くの場合不要です。その理由は、Eloquentが採用するActive Recordパターンにあります。

Active Recordはデータとロジックを統合したパターンであり、モデル自身がデータアクセスの責務を担っています。その上にさらにRepositoryレイヤーを重ねるのは責務の重複であり、本質的な価値をもたらしません。Repositoryパターンが自然に機能するのは、ドメインモデルとデータアクセスが分離されたData Mapperパターン（Doctrineなど）との組み合わせでしょう。

また、Laravelの多くの機能はEloquentに深く統合されています。リレーション、Eager Loading、イベント、Observerといった機能群は、Eloquentを前提として設計されています。Eloquentを使わないなら、Laravelを選択する理由そのものが希薄になります。

Laravelの標準的なアーキテクチャは、ControllerからService層やActionクラスを呼び出し、その中でEloquent Modelを利用する形を基本とします。クエリロジックはクエリスコープやモデルメソッドでカプセル化します。より複雑なクエリが必要なら、Query ObjectsやQuery Buildersで専用クラスに分離すればよいでしょう。単一責任のビジネスロジックには、ActionsやCommandsといったパターンが有効です。

ただし例外もあります。複数のデータソース（データベース、API、キャッシュ等）を統一インターフェースで扱う必要がある場合や、チーム規約として厳密なレイヤー分離が求められる場合には、Repositoryパターンが有用な選択肢となりえます。重要なのは、パターンを盲目的に適用するのではなく、実際の要件に基づいて判断することです。