1. Webフレームワークが抽象化しているもの

JavaでWebアプリを作る場合、最小単位はServletです。しかしServletは極めて低レベルで、以下を自前実装する必要があります。

• URLとメソッドのマッピング
  
• リクエストボディのパース
  
• パラメータバリデーション
  
• 例外の統一ハンドリング
  
• トランザクション開始終了制御
  
• オブジェクト生成と依存解決

これらは業務ロジックとは無関係な「横断的関心事」です。

JavaのWebフレーム ワーク は、これらを統一ルールのもとで抽象化し、再利用可能な基盤として提供します。

つまり「共通問題の標準化」が本質です。

2. Servletの役割とコンテナ内部動作

ServletはHTTPとJavaクラスを接続する仕様です。

実行フロー

1. ブラウザがHTTPリクエスト送信
2. Servletコンテナ（例：Tomcat）がポートで受信
3. スレッドプールからスレッドを割り当て
4. 対象Servletのservice()メソッドを呼び出し
5. doGet/doPostへディスパッチ
6. HttpServletResponseに書き込み

重要なのは「Servletはマルチスレッドで動く」という点です。

インスタンスは基本的に1つで、複数スレッドが同時に呼び出します。

ここを理解していないと、インスタンス変数に状態を持たせてバグを生みます。

フレームワークはこの上にDispatcher構造を構築します。

3. MVCとは依存方向を固定する設計装置

MVCは単なる役割分担ではありません。

依存方向を一方向に固定する仕組みです。

RepositoryはControllerを知りません。

これが変更耐性を生みます。

もしControllerがDB処理を直接書くと、以下の問題が起きます。

• テストが困難
  
• トランザクション境界が曖昧
  
• 責務が肥大化

MVCは「変更の波及を止めるための構造」です。

4. フレームワークが必要になる本当の理由

実務では次の問題が必ず発生します。

• トランザクション管理

Service層で開始し、例外時にロールバック。

これを毎回try-catchで書くのは非現実的です。

• 依存関係の爆発

ControllerがServiceをnewし、ServiceがRepositoryをnewする。

これではテストで差し替え不能です。

• 横断的関心事

ログ出力、認証、監査、キャッシュ。

これらは全メソッドに影響します。

フレームワークはAOPとDIでこれを制御します。

5. Java Webアプリのレイヤー構造と実行フロー

典型構造：

重要なのはトランザクション境界がServiceにあること。

ControllerでDB操作をすると、トランザクション設計が崩れます。

JavaのWebフレーム ワーク は、この構造を自然に書けるように設計されています。

6. 主要フレームワーク分類と思想の差

実装主導型

代表例：Spring Boot

• 実装中心で進化
  
• Auto Configuration
  
• マイクロサービス向け

柔軟で拡張性が高い。

仕様主導型

代表例：Jakarta EE

• 標準API群を定義
  
• アプリケーションサーバー前提
  
• 統制を重視

大規模組織向け。

旧世代型

代表例：Struts

• XML設定中心
  
• 明示的マッピング

保守案件で現存。

違いは「思想」と「運用モデル」です。

7. Spring Bootの内部メカニズム詳細

Spring Bootの起動時処理：

1. メインクラス実行
2. ApplicationContext生成
3. コンポーネントスキャン
4. Bean定義登録
5. 組み込みTomcat起動
6. DispatcherServlet登録

リクエスト時：

1. HandlerMappingがController探索
2. HandlerAdapterがメソッド実行
3. 戻り値をHttpMessageConverterが変換
4. レスポンス返却

DIコンテナがすべてのBeanライフサイクルを管理します。

8. Jakarta EEのアーキテクチャ思想

Jakarta EEは仕様集合体です。

• Servlet
  
• JPA
  
• CDI
  
• JAX-RS

ベンダーが仕様を実装し、アプリは仕様に依存します。

思想は「標準準拠と安定性」。

企業基幹系では依然有力です。

9. トランザクション管理とAOPの裏側

@Transactionalの内部では、

• プロキシ生成
  
• メソッド呼び出し前にトランザクション開始
  
• 例外検知でロールバック
  
• 正常終了でコミット

という処理が挿入されます。

これはAOP（Aspect Oriented Programming）による横断的制御です。

これを理解せずに使うと、自己呼び出し問題などで混乱します。

10. 学習ロードマップ（理解を深める順序）

1. Java基礎（例外インターフェースアノテーション）
2. HTTPとステートレス概念
3. 素のServletを実装
4. Spring Bootで同機能を実装
5. DIとAOPの内部を追う
6. トランザクション境界を意識した設計

Servletを書かずにSpringを学ぶと、抽象化の意味が理解できません。

11. よくある誤解を構造的に否定する

誤解1: フレームワークが設計を保証する

→ 構造を守らなければ崩壊します。

誤解2: Springだけ覚えれば十分

→ Jakarta EEが標準指定の企業も存在します。

誤解3: MVCは古い

→ Webのリクエスト駆動モデルと相性が良い。

誤解4: 設定が少ない＝優秀

→ 明示的構造の方が長期保守に強い場合もある。

JavaのWebフレーム ワーク とは、Servletを基盤にMVC構造、DIコンテナ、トランザクション管理、AOPによる横断的制御を統合した抽象化レイヤーです。ServletがHTTP処理を担い、その上でSpring BootやJakarta EEが設計思想を実装します。重要なのはフレームワーク名ではなく、依存方向、トランザクション境界、DIの仕組みを理解することです。初心者はまずServletを書き、その後Spring Bootで同じ処理を実装し、内部構造を追うことで理解が飛躍的に深まります。フレームワークは便利な道具ですが、本質は設計原則と構造理解にあります。