コラム: 過剰設計の罠
クリーンアーキテクチャを学ぶと、全てのプロジェクトに適用したくなります。しかし、アーキテクチャは目的ではなく手段です。
アーキテクチャは銀の弾丸ではない
よくある失敗パターン
┌─────────────────────────────────────────────┐
│ 過剰設計の兆候 │
├─────────────────────────────────────────────┤
│ │
│ 「クリーンアーキテクチャを適用しました！」 │
│ │
│ 結果: │
│ ├── 100行で済むコードが1000行に │
│ ├── シンプルなCRUDに10個のクラス │
│ ├── 誰も全体像を把握できない │
│ ├── 新しいメンバーが理解に1週間 │
│ └── 「ちょっとした修正」に半日 │
│ │
│ これは成功ではない │
│ │
└─────────────────────────────────────────────┘
なぜこうなるのか
┌─────────────────────────────────────────────┐
│ 過剰設計の原因 │
├─────────────────────────────────────────────┤
│ │
│ 1. 「正しさ」への執着 │
│ └── 教科書通りにやらないと不安 │
│ │
│ 2. 将来の変更への過度な備え │
│ └── 「いつかDBを変えるかも」 │
│ （実際には変えない） │
│ │
│ 3. 複雑さ = 良い設計という誤解 │
│ └── シンプルな解決策を軽視 │
│ │
│ 4. 他のプロジェクトの真似 │
│ └── 大規模プロジェクトの構成を │
│ 小規模プロジェクトに適用 │
│ │
└─────────────────────────────────────────────┘
いつクリーンアーキテクチャが必要か
必要なとき
┌─────────────────────────────────────────────┐
│ クリーンアーキテクチャが有効なケース │
├─────────────────────────────────────────────┤
│ │
│ ✓ 長期間メンテナンスするプロダクト │
│ └── 変更の影響を限定したい │
│ │
│ ✓ 複雑なビジネスロジックがある │
│ └── ロジックを技術的詳細から分離したい │
│ │
│ ✓ 技術選択が変わる可能性がある │
│ └── DBやフレームワークを変えるかも │
│ │
│ ✓ テスト容易性が重要 │
│ └── ビジネスロジックを単独でテストしたい │
│ │
│ ✓ 複数チームで開発する │
│ └── 境界を明確にして独立して開発したい │
│ │
└─────────────────────────────────────────────┘
不要なとき
┌─────────────────────────────────────────────┐
│ シンプルな構成で十分なケース │
├─────────────────────────────────────────────┤
│ │
│ ✗ 短期間のプロトタイプ │
│ └── 動くことが最優先 │
│ │
│ ✗ 単純なCRUDアプリ │
│ └── 複雑なビジネスロジックがない │
│ │
│ ✗ 使い捨てのスクリプト │
│ └── メンテナンスの必要がない │
│ │
│ ✗ 技術検証用のコード │
│ └── 構造より速度が大事 │
│ │
│ ✗ 一人で開発する小規模プロジェクト │
│ └── 全体を把握できるサイズ │
│ │
└─────────────────────────────────────────────┘
判断の基準
YAGNI: You Aren't Gonna Need It
┌─────────────────────────────────────────────┐
│ YAGNIの原則 │
├─────────────────────────────────────────────┤
│ │
│ 「それ、本当に必要？」 │
│ │
│ 「いつかDBを変えるかも」 │
│ → 今、変える予定はあるのか？ │
│ → ないなら抽象化は不要かもしれない │
│ │
│ 「将来、UIが変わるかも」 │
│ → 今、その兆候はあるのか？ │
│ → ないなら境界は後から引ける │
│ │
│ 必要になったときに対応すればいい │
│ │
└─────────────────────────────────────────────┘
今ある痛みに対処する
┌─────────────────────────────────────────────┐
│ 痛みベースの判断 │
├─────────────────────────────────────────────┤
│ │
│ 良い理由: │
│ ├── 「テストが書けなくて困っている」 │
│ ├── 「DBの変更が全体に波及して大変」 │
│ └── 「ロジックがControllerに混在して複雑」 │
│ │
│ 悪い理由: │
│ ├── 「教科書にそう書いてあったから」 │
│ ├── 「他のプロジェクトがやっていたから」 │
│ └── 「クリーンアーキテクチャって名前がいい」│
│ │
│ 今ある問題を解決するために使う │
│ 将来の問題を予測して使わない │
│ │
└─────────────────────────────────────────────┘
段階的に導入する
最初から完璧を目指さない
┌─────────────────────────────────────────────┐
│ 段階的なアプローチ │
├─────────────────────────────────────────────┤
│ │
│ Step 1: シンプルに始める │
│ └── まず動くものを作る │
│ 最小限の構造で │
│ │
│ Step 2: 痛みを感じたら対処 │
│ └── テストが書きにくい │
│ → その部分に境界を導入 │
│ │
│ Step 3: 必要に応じて拡張 │
│ └── 複雑さが増してきた │
│ → 境界を増やす │
│ │
│ 育てていくイメージ │
│ │
└─────────────────────────────────────────────┘
リファクタリングで対応できる
┌─────────────────────────────────────────────┐
│ 後から直せる │
├─────────────────────────────────────────────┤
│ │
│ 「最初から完璧な設計にしないと」 │
│ → そんなことはない │
│ │
│ コードは後から構造を変えられる │
│ ├── インターフェースを抽出する │
│ ├── クラスを分割する │
│ └── 層を導入する │
│ │
│ 最初から完璧を目指すより │
│ 必要になったときに対応する方が │
│ 結果的に良い設計になることが多い │
│ │
└─────────────────────────────────────────────┘
まとめ
アーキテクチャは手段
┌─────────────────────────────────────────────┐
│ 覚えておくべきこと │
├─────────────────────────────────────────────┤
│ │
│ クリーンアーキテクチャは: │
│ ├── 目的ではなく手段 │
│ ├── 銀の弾丸ではない │
│ └── 全てのプロジェクトに必要ではない │
│ │
│ 必要なのは: │
│ ├── 今ある問題を解決すること │
│ ├── チームが理解できる複雑さに留めること │
│ └── 必要になったときに導入すること │
│ │
└─────────────────────────────────────────────┘
シンプルさを忘れない
「この複雑さは、本当に必要か？」
常にこの問いを持ち続ける
シンプルなコードは:
├── 理解しやすい
├── 変更しやすい
├── バグが少ない
└── それ自体が良い設計