💡 独学者が語る！PHP 独自 MVC から学んだ「真の責務の分離」とは

導入：MVC とは「設計思想」である

私が長年 Web サイトを運用してきた中で、最初に手探りで取り入れた設計パターンが MVC (Model-View-Controller) でした。このパターンのおかげで、当時のスパゲッティコードから脱却し、システムに一定の秩序をもたらすことができました。

しかし、私が自作した PHP 独自 MVC は、サイトが成長するにつれて致命的な保守性の問題に直面しました。この経験を通じて痛感したのは、**「MVC は単なる三層のフォルダ構造ではない。真の責務の分離とは、データとロジック、表示の境界を厳格に守ることである」**という原則です。

本記事では、私が独自 MVC の運用で直面した**「偽りの分離」の課題と、モダンな Next.js (React)/Django への移行を通じて学んだ「真の責務の分離」**の教訓を解説します。

---

第1章：独自 MVC で陥った「偽りの責務分離」の罠

1. Controller の肥大化（Fat Controller）問題

独学者が自作 MVC で最も陥りやすい罠が、Controller の肥大化 (Fat Controller) です。私の旧システムも例に漏れず、Controller が以下のような複数の責務を抱え込んでいました。

• データ取得: Model を呼び出すだけでなく、複雑なデータ集計クエリを Controller 内で直接生成してしまう。
• 業務ロジック: ユーザーの入力検証、条件分岐、外部 API との連携処理など、様々な業務ロジックを Controller に記述。
• View への依存: データを View に渡す前に、Controller 側で View の表示形式に合わせた加工処理をしてしまう。

これにより、Controller はすぐに数百行のコードの塊となり、一つの処理を変更するだけで、予期せぬ別の機能が壊れるという「恐怖のコード」と化しました。

2. Model の持つべきでない「画面ロジック」

Controller が肥大化する裏側で、Model もまた不適切な責務を負っていました。

• HTML 生成コードの混入: Model の中でデータ加工処理を行った際、その結果を HTML のタグで装飾して View に返してしまう（例：<div> や <br> を Model 内部で生成）。
• 外部サービスとの密結合: Model が特定の外部 API のデータ形式に強く依存してしまい、API 側の仕様変更で Model 全体の修正が必要になっていました。

真の Model は、**「データとビジネスロジックに集中すること」**が責務ですが、私の初期の MVC は、その境界線が曖昧でした。

3. View の「多すぎるロジック」

PHP で書かれた View ファイルでは、データを表示するだけでなく、if や foreach などの制御構造を複雑に入れ子にしていました。

• 問題: View でロジックを書きすぎると、View は単なるテンプレートではなくなり、テストが困難な「表示ロジックとデザインが混在した塊」になってしまいます。

---

第2章：モダン Full-Stack が実現する「真の責務の分離」

Next.js (React)/Django への移行は、単に言語が変わっただけでなく、フレームワークによる厳格な規約が、真の責務分離を強制してくれました。

1. Controller の消滅と View/Business Logic の分離

モダンな構成では、Controller の役割は、API サーバー（Django）と UI レイヤー（Next.js）に分離・吸収されました。

• Django (API サーバー):
  • DRF ViewSets: Controller のリクエスト受付とルーティングの責務を担います。しかし、内部の業務ロジックは全て Model/Service 層に分離されています。
  • Model/Service 層: ここが**「真のビジネスロジック」**を担う場所です。複雑なデータ集計やビジネスルールは、Controller から完全に切り離された Python クラスとして記述され、テスト容易性が確保されました。
• Next.js (UI レイヤー):
  • Server Components: Controller が行っていたデータ取得の呼び出しと、View（React Component）へのデータ受け渡しを担います。

2. Model は「データそのもの」に集中する

Django ORM の Model は、データベースとの連携とデータ検証に集中し、View や Controller の都合に影響されなくなりました。

• Serializer の活用: データと JSON の変換は DRF Serializer が担当し、Model が HTML 形式や API 形式を意識する必要が一切なくなりました。
• PostgreSQL の活用: 複雑なデータ集計は、Model の持つ ORM の能力を最大限に引き出す形で実現され、Model の責務は「堅牢なデータ層」として確立されました。

3. View は「表示」に集中する (React Component)

Next.js の React Component は、View の責務を極めて厳格に守ります。

• ロジックの排除: Tailwind CSS を用いてスタイルが Component 内部に閉じ込められ（View の責務の範囲内）、API から渡されたデータを加工・整形せずに表示することに集中できます。
• Hooks の活用: 状態管理や副作用といったロジックは、カスタム Hooks に分離され、View のレンダリングコードをシンプルに保つことができます。

---

まとめ：設計原則こそが独学者の羅針盤

1. 真の責務の分離がもたらす効果

「真の責務の分離」を実現したことで、プロジェクト全体に以下の効果がもたらされました。

• バグの発生源の特定容易性: 問題が API 層にあるのか、ビジネスロジック層にあるのか、UI 層にあるのかが明確になり、デバッグ時間が大幅に削減されました。
• 再利用性の向上: Django の Service 層で記述したビジネスロジックは、Web API だけでなく、将来的にコマンドラインツールやモバイル API としても容易に再利用できるようになりました。
• 保守性の向上: 開発者が修正を加えるべきファイルを迷うことがなくなり、コード変更による意図しない影響（バグ）の範囲を限定できるようになりました。

2. 独学者が身につけた「設計思想」

独学で Web 開発を始めた頃は、フレームワークの機能や言語の文法を覚えることに必死でした。しかし、この大規模な移行プロジェクトを通じて、**「技術は変わっても、設計原則は不変である」**という最も重要な教訓を学びました。

MVC の真の力は、コードを分割することではなく、未来の保守と拡張を見据えて、コードの役割（責務）を厳密に定義し、守り抜く設計思想にあります。この設計思想こそが、私がチーム開発で貢献できる最大の強みです。

今後も、この設計原則を羅針盤として、堅牢で拡張性の高いシステム開発を追求していきます。