コラム: フレームワークを「卒業」するとき
フレームワークは開発を加速させる強力なツールです。しかし、プロジェクトが成熟するにつれて、フレームワークの制約が足かせになることがあります。
フレームワークの恩恵
最初は大きなメリットがあります：
┌─────────────────────────────────────────────┐
│ フレームワークがもたらすもの │
├─────────────────────────────────────────────┤
│ │
│ ・すぐに開発を始められる │
│ ・ベストプラクティスが組み込まれている │
│ ・ドキュメントやコミュニティがある │
│ ・チームメンバーが学びやすい │
│ │
└─────────────────────────────────────────────┘
制約が見えてくるとき
プロジェクトが成長すると、こんな場面に遭遇します：
┌─────────────────────────────────────────────┐
│ フレームワークとの摩擦 │
├─────────────────────────────────────────────┤
│ │
│ 「この処理、フレームワークの想定と違う...」 │
│ 「回避策ばかり書いている気がする」 │
│ 「アップグレードのたびに大変な修正が...」 │
│ 「パフォーマンスが出ない、でも手が出せない」│
│ │
└─────────────────────────────────────────────┘
具体的なサイン
卒業を検討すべきサイン:
├── フレームワークの制約を回避するコードが増えている
├── 「フレームワークがこうだから」で設計が歪んでいる
├── 内部実装を読まないと問題が解決できない
├── バージョンアップが怖くてできない
└── 必要な機能の10%しか使っていない
「卒業」の形
フレームワークを完全に捨てる必要はありません。段階的なアプローチがあります。
レベル1: 部分的な置き換え
フレームワークの一部機能だけ自作:
├── 認証部分だけ独自実装
├── データアクセス層だけ独自実装
└── 特定のコンポーネントだけ独自実装
フレームワークの基盤は活かしつつ
必要な部分だけコントロールを取り戻す
レベル2: 薄いラッパーとして使う
フレームワークを「インフラ」として使う:
├── HTTPサーバーとしてだけ使う
├── ルーティングだけ使う
└── 設定管理だけ使う
ビジネスロジックはフレームワークに依存しない
レベル3: 完全な移行
フレームワークを完全に外す:
├── 軽量なライブラリの組み合わせに移行
├── 独自フレームワークを構築
└── 別のフレームワークに移行
idp-serverのアプローチ
idp-serverはSpring Bootを使いつつ、多くの機能を自作しています：
┌─────────────────────────────────────────────┐
│ Spring Bootの使い方 │
├─────────────────────────────────────────────┤
│ │
│ 使っているもの（インフラ層）: │
│ ├── HTTPサーバー（組み込みTomcat） │
│ ├── ルーティング（@GetMapping等） │
│ └── 設定管理（application.yml） │
│ │
│ 使っていないもの（自作）: │
│ ├── DI（コンストラクタ注入を手動で） │
│ ├── データアクセス（独自Repository） │
│ └── セキュリティ（独自実装） │
│ │
└─────────────────────────────────────────────┘
これは「レベル2」のアプローチです。
なぜこの選択をしたか
理由:
├── OAuth/OIDC仕様への厳密な準拠が必要
├── Spring Securityの抽象化が仕様と合わない
├── 細かいパフォーマ ンスチューニングが必要
└── 長期的な保守性を重視
結果:
├── フレームワークの便利さは享受しつつ
├── コア部分は完全にコントロール
└── 仕様変更にも柔軟に対応可能
卒業の判断基準
卒業すべきとき
✓ フレームワークの制約がビジネス要件を妨げている
✓ 回避策のコードが本質的なコードより多い
✓ チームがフレームワークの内部を熟知している
✓ 長期的に保守する覚悟がある
✓ 移行コストを許容できる
卒業すべきでないとき
✓ 「なんとなく」フレームワークが嫌なだけ
✓ チームにフレームワークなしで開発する力がない
✓ 短期的なプロジェクト
✓ 移行コストが見合わない
✓ フレームワークの恩恵をまだ受けている
まとめ
┌─────────────────────────────────────────────┐
│ フレームワークとの付き合い方 │
├─────────────────────────────────────────────┤
│ │
│ 初期: フレームワークに乗っかる │
│ → 開発速度を最大化 │
│ │
│ 成長期: 制約を感じ始める │
│ → 部分的に自作を検討 │
│ │
│ 成熟期: 必要に応じて「卒業」 │
│ → コントロールを取り戻す │
│ │
│ フレームワークは「使うもの」であって │
│ 「従うもの」ではない │
│ │
└─────────────────────────────────────────────┘
フレームワークを卒業することは「裏切り」ではありません。プロジェクトが成熟した証です。