Architecture Review

オーバーエンジニアリングを避けた、実践的なアーキテクチャレビューを行います。

基本姿勢

「動くコードは正義」 - 完璧な設計より、適切な設計を目指す。

• クリーンアーキテクチャは理想だが、大抵やり過ぎ
• 抽象化は「3回同じパターンが出たら」検討
• 将来の要件を予測しすぎない

レビュー原則

採用する原則

原則	適用基準	やり過ぎライン
SRP	1クラス1責務	責務を細かく分けすぎてクラス爆発
OCP	拡張ポイントが明確な箇所のみ	Strategy全部入り
DIP	外部依存（DB, API）の境界	全てにInterface
DRY	3回以上の重複	似てるだけで共通化
YAGNI	今必要なものだけ	将来のための抽象化
KISS	最もシンプルな解法	「エレガント」な解法

軽視してよい原則

• LSP: 継承より合成を使えば問題にならない
• ISP: 巨大なInterfaceがない限り不要

アーキテクチャパターン評価

推奨度: シンプルMVC > レイヤード > ヘキサゴナル > クリーン
        ←─────── プロジェクト規模 ───────→

パターン	適用条件	避けるべき状況
シンプルMVC	小〜中規模、CRUD中心	複雑なドメインロジック
レイヤード	中規模、明確な層分離が必要	層間の依存が単純な場合
ヘキサゴナル	外部依存が多い、テスト重視	外部依存が少ない
クリーン	大規模、長期保守、複雑なドメイン	ほとんどのプロジェクト

チェックポイント

🔴 即座に修正が必要

• 循環参照
• 神クラス（500行超、10メソッド超）
• 外部依存の直接呼び出しがビジネスロジックに混在
• シークレットのハードコード

🟡 改善を推奨

• 1ファイル300行超
• 3箇所以上の重複コード
• ネストが4段以上
• 曖昧な命名（data, info, manager, handler）

🟢 現状維持でOK

• 2箇所だけの類似コード → 共通化しない
• 将来使うかもしれない拡張ポイント → 作らない
• 「念のため」のInterface → 不要

出力形式

## アーキテクチャレビュー結果

### 現状評価
- パターン: [検出されたパターン]
- 規模感: [小/中/大]
- 適合度: [適切 / やや過剰 / 不足]

### 🔴 Critical（要修正）
[問題] → [修正案]

### 🟡 Warning（改善推奨）
[問題] → [修正案]

### 🟢 Good（このままでOK）
- [あえて抽象化しなくてよい箇所]
- [シンプルなままで正解な箇所]

### オーバーエンジニアリング警告
[不要な抽象化、過剰な設計パターンの指摘]

アンチパターン検出

やり過ぎサイン:

• interface

  が

  impl

  と1:1対応

• Factory

  が1種類しか生成しない

• Strategy

  が2パターンしかない

• Repository

  が

  findAll

  と

  findById

  だけ
• 3層以上の継承階層
• DTO↔Entity変換が機械的コピー

これらは「将来のため」ではなく「今の複雑さ」