高いビジネスロジックはDBやLaravelの機能に依存させないLaravelのModelにビジネスロジックを書いてしまうとEloquent依存のコードを簡単にかけてしまいます。動かすにはこれが一番早いので選択肢としてはありかと思いますが、後に機能が複雑になってくるとテスト結果がDBの状態になったりテストがしにくくなるのでやめましょうとはいえEloquentは便利なのでRepository内で使いましょうできるところはLaravelに依存するログイン、ページネーション、バリデーションなどはLaravelに依存しましょう。できる限りテストを簡単にテストを簡単にかけるような設計でないとテスト書くのが苦痛になり、テストが雑になりがちです。解決策DDDや、クリーンアーキテクチャはそのまま導入しようとしましたが、現状に対してあまりに壮大過ぎる&チームでやるには学習コストが高すぎるので以下を導入することにしました。Modelからビジネスロジックを分離させるEntitiesディレクトリを新規に作成し、ここに重要度が高いビジネスロジックをModelに依存させない形で作成します。LaravelのFacadeも使ってはいけません。CakePHPやWordPressにそのままコピペできるようにしましょう。}}Repository層の導入Repositoriesディレクトリを作成し、ここでEloquentを使いながら上のEntityを作成します。app/Repositoriesにインターフェイスを作成します。インターフェイスを作成することでデータベースへの依存を防げます。?Video;}app/Repositories/implに実際にEloquentを使った組み込みを書いていきます。$video->author}}サービスプロバイダーを追加し、VideoRepositoryとVideoDBRepositoryをバインドします。これでVideoRepository参照するとVideoDBRepositoryが読み込まれます。VideoRepositoryに依存することにより入れ替えで簡単にテストができます。}}実際にリポジトリを使用する時はコンストラクタインジェクションを使います。サービス・プロバイダーでbindしているのでInterfaceからアクセス可能です。}}まとめControllerはRepositoryのIntarfaceに依存しているので、ControllerはDBを意識しないでよくなりました。テスト用のMockRepositoryでも、DBではなくAPIで永続化をするApiRepositoryでもimpl組み込みを追加しbindし直すだけで対応が可能になりました。EntityではRepositoryもControllerも意識する必要がありません。ロジックのテストにDBの依存が入らないのでテストがやりやすくなります。upLoginユーザーは見つかりませんでした。