MVC
概要
Controllerが入力を受け、Modelに仕事をさせ、Viewに結果を描かせる
MVCは「UIとそれ以外を分離するための最初の抽象」
目的は「関心の分離」。特に守りたいのは、UI変更が業務ロジックを壊さないこと。
Mは「それ以外」なのでMが広いのは仕様であり欠陥でもある
MVCが優れている点
学習コストが低い
UI分離という最重要論点を押さえている
MVCの限界
業務の複雑さは扱えない
変更理由の分離ができない
長寿命・高変更頻度なプロダクトでは不足
MVCの要素
Model
ビジネスルール
状態遷移
永続化
ドメインロジック
View
表示への変換（HTML/JSON）
Controller
ルーティング
ユースケースの入り口
パラメータの受け取り
Model（またはUseCase/Service）への処理委譲
Viewの選択
MVCは1軸の分離しか持たない
UIか？
それ以外か？
変更理由（なぜ変わるか）までは扱わない
そのため、Mが肥大化しやすい
問題点
Controllerにユースケース全部書いてしまう問題
Controllerにトランザクション管理、3つぐらいのModelを跨いだ更新、外部サービスAPI呼び出し、イベント発行などを全部書いてしまってテストしづらく、変更容易性が低い状態になる
ビジネスロジックがModelに集中して〇〇Service/〇〇Managerみたいな神クラスみたいなのができてしまいがち
密結合
ビジネスロジックがデータアクセスなどのDaoと蜜結合になってしまう
規模が大きくなるにつれてMの負担が大きくなって管理が大変になる
依存の方向性
安定しているドメイン層が安定していないインフラ層に依存/蜜結合してしまう
共通する狙いはだいたい同じで、「ドメインロジックをUIやインフラから切り離す」「テストしやすく、変更に強い状態にする」 MVCが苦しくなったら、次の抽象へ
「UIかどうか」ではなく
「なぜそれが変わるのか」で構造を分けること(Mの内側の整理)
業務が変わる
ユースケースが変わる
技術が変わる
👉 変更理由をコード構造に刻む
MVCは外枠
次の抽象（Clean / Hexagonalなど）は中身の整理
MVC（外）
Model（中）
Domain（業務ルール）
Application（ユースケース）
Infrastructure（DB / 外部）
👉 MVCは消えない
👉 相対化される
MVCはアーキテクチャなのか？
MVCはアーキテクチャというよりは設計思想に近い
アーキテクチャが本来答える問い
どんなコンポーネントが存在するか
それらはどう依存するか
何が内側で、何が外側か
何を守り、何を変えてよいか
しかし、MVCが答えるのはこれだけ。
UIか？
それ以外か？
MVCは「関心をどう分けて考えるべきか」を示す思考の枠組み
言い換えると
分離の方向性を示す
実装の自由度を残す
厳密さより理解しやすさを優先
👉 設計思想
code:text
設計思想（Paradigm）
└─ MVC
アーキテクチャ（制約の集合）
├─ Clean Architecture
├─ Hexagonal Architecture
└─ Onion Architecture
ざっくりイメージ