arch-review

Architecture Review

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

基本姿勢

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

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

レビュー原則

採用する原則

軽視してよい原則

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

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

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

チェックポイント

🔴 即座に修正が必要

• 循環参照
• 神クラス（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変換が機械的コピー

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