厨房で皿を洗う店長
「全部私がやります！」
責任感が強いのは結構ですが、店長（Controller）が自ら包丁を握り、
接客をし、トイレ掃除までしていたら、その店はいつか破綻します。
- Controllerクラスの行数が1000行を超えている
- 「ビジネスロジック」を書く場所が決まっておらず、Controllerに書いている
- 同じような処理（メール送信など）が複数のControllerにコピペされている
- 修正すると、全く関係ないはずの画面が壊れる
どこに何があるか、書いた本人にしか（数日後には本人ですら）分かりません。
01. 店長の仕事、シェフの仕事
public function store(Request $req) {
// バリデーションして...
// 在庫引当のSQLを書いて...
// クレジットカード決済APIを叩いて...
// 注文完了メールの本文を作成して...
// ログを書いて...
MVCモデルにおける「Controller」の役目は、レストランの「店長（マネージャー）」と同じです。
店長の仕事は、「お客様の注文（Request）」を受け取り、「シェフ（Model/Service）」に料理を指示し、
出来上がった料理を「ホール係（View）」に渡すことだけです。
しかし、未熟なプロジェクトでは、店長自らが厨房に入り込み、肉を焼き、皿を洗い、レジ打ちまでしてしまいます。
これを「Fat Controller（太ったコントローラー）」と呼びます。
何でも屋になった店長は過労で倒れ、店（システム）は停止します。
「動かし続ける」ことができない。
02. 餅は餅屋に
複雑な処理は、専門家（Serviceクラス）に任せるべきです。
在庫管理は `InventoryService` に、決済は `PaymentService` に。
Controllerは、彼らを呼び出す「1行」を書くだけでいいのです。
「Skinny Controller, Fat Model（痩せたコントローラー、太ったモデル）」を目指しましょう。
役割分担が明確な組織（コード）は、誰かが休んでも（修正しても）、全体に影響を与えません。
03. テスト不能な巨大迷路
Controllerにロジックを詰め込むと、自動テスト（単体テスト）が書けなくなります。
HTTPリクエスト全体をモックしなければならないからです。
ロジックを切り出していれば、「在庫計算ロジック」だけをピンポイントでテストできます。
テストがないコードは、時限爆弾と同じです。
爆発する前に、解体（リファクタリング）工事を始めましょう。