【DAY38】Laravelに直接保存ロジックを書くと設計が破綻しやすい理由

【DAY38】Laravelに直接保存ロジックを書くと設計が破綻しやすい理由

Laravelで開発を始めたばかりの頃、「コントローラーでリクエストを受け取って、バリデーションして、モデルに値を渡して保存する」という流れで構築する人は多いと思います。確かにこれで動きますし、Laravelのドキュメントにも載っている方法です。しかし、機能が増えていくと、このアプローチは急激に破綻していきます。

問題は、アプリケーションロジックが肥大化しやすい点です。たとえば「ユーザーが記事を投稿したら通知を送る」「ログを記録する」「ポイントを付与する」といったドメイン固有の処理を追加しようとすると、コントローラーやモデルに直接ロジックを書き足していくしかありません。結果として、単一責任の原則が崩れ、変更に弱い設計になります。

Laravelではサービス層（Serviceクラス）を導入することで、これらの処理をモデルやコントローラーから分離できます。例えば以下のような構成が考えられます：

• ArticleController: HTTPの入口。バリデーションとサービス呼び出しだけを行う。
• ArticleService: 投稿処理の流れ（保存、通知、ログ記録など）をまとめる。
• Article: Eloquentモデル。DBとのやりとりに専念する。

この分離により、ユニットテストが書きやすくなり、テスタビリティも向上します。例えば、ArticleService に対してモックを使ってテストを行えば、通知機能だけを個別にテストすることが可能です。コントローラーやモデルに直接処理を書いていた場合、外部サービスやDBに依存したテストになってしまい、テストの実行コストが跳ね上がります。

また、ビジネスロジックが散らばらず、一箇所にまとまることで、将来的な仕様変更にも対応しやすくなります。たとえば保存処理に条件分岐が増えた場合でも、ArticleService だけを編集すれば済むため、影響範囲が明確になります。

Eloquentは非常に強力で、ついモデルに多くの処理を書きたくなります。しかし、柔軟性が高いからこそ、意識して責務を分離しないとすぐにスパゲッティ化します。

アプリケーションがスモールスタートでも、「サービス層を使う癖」をつけておくと、将来的にメンテナンス性が高く、チーム開発にも耐えられる設計になります。Laravelに直接保存ロジックを書くのは簡単ですが、複雑化したときの代償は決して小さくありません。