Laravelが「オンプレ前提でクラウドと相性が悪い」「時代遅れ」なのだろうか。だが実際には事情はもう少し複雑なのではないだろうか。Laravelは総合型（バッテリー同梱）フレームワークでありつつ、内部はある程度疎結合にできている。ただし、それは「総合型の中の疎結合」であり、自由度の幻想にすぎない部分もあるという話？
クラウドとの親和性は本当に低いのか？
LaravelはAWSやコンテナ環境でも普通に動くし、キュー（Redis/SQS）、ストレージ（S3）、セッションやキャッシュの切り替えも簡単にできる。問題は「最初にファイルシステムや状態を前提に作ってしまったアプリを、あとから分散・無状態に直すコスト」が大きいことにある。フレームワークの本質的な問題というより「最初の設計判断がその後に響く」だけの話にすぎないのではないか。
総合型の中の疎結合
Laravelは多機能を一式で提供する「総合型フレームワーク」だ。認証、ORM、テンプレート、スケジューラまで一揃い入っている。ただし内部は Illuminate コンポーネント群として分割され、ある程度はモジュール的に入れ替えられる。つまり「全部まとめて」でも「必要なところだけ」でも使える設計にはなっている。しかし、フレームワーク初心者が「最速で動く方法（推奨のやり方）」を写経すると、結局はフレームワークにガッツリ依存したコードが生まれやすい。この辺が「自由度が高いようで依存度も高い」と言えるのかもしれない。
MVCの柔軟性と限界
MVCは分かりやすい構造を与えるが、複雑なビジネスルールを扱うとすぐに限界が見える。「Fat Controller（コントローラにロジック集中）」や「Anemic Model（データだけのモデル）」という失敗例は有名だ。これを乗り越えるために登場するのがDDD（ドメイン駆動設計）、クリーンアーキテクチャ、ヘキサゴナルなどのパターンだ。要するに「MVCは入口としては良いが、出口にするには狭すぎる」という話ではないか。
スモールスタートの罠
現場ではよく「まず小さく動くものを」と経営者が言い、結果的にその小さなシステムが基幹に成長していく。そのとき、最初の設計選択がそのまま技術的負債になる。時間もリソースも限られた現実の中では、Bounded ContextやAPI分割、テストの早期導入など、理想の対応策を全部実践できることはほとんどない。だからこそ「Laravelは時代遅れ」などという単純な批判よりも、「初期の選択ミスが後々痛む」現実を直視すべきだろう。
COBOLに感銘を受ける？
最後に突然COBOLを持ち出し「感銘を受けた」と言われると、ネタなのか本気なのか分からず崖から突き落とされた気分になる。しかし一理あるのかもしれない。COBOLは業務処理の可読性と保守性を重視し、結果として数十年生き残ってきた言語だ。グレース・ホッパーが高水準言語の先駆けとして磨き上げたその設計思想は、むしろ「モダン」の原点に近い。
結論
COBOLでWebシステムを作ろう（！）
コメント