このアーキテクチャをレビュー：
[アーキテクチャ図またはコード]

評価項目:
- SOLID原則
- スケーラビリティ
- 保守性

// ❌ 複数の責任
class User {
  saveToDatabase() {}
  sendEmail() {}
  generateReport() {}
}

// ✅ 単一責任
class User {}
class UserRepository {
  save(user: User) {}
}
class EmailService {
  send(to: string) {}
}
class ReportGenerator {
  generate(user: User) {}
}

# ❌ 具象に依存
class UserService:
    def __init__(self):
        self.db = MySQLDatabase()  # 具象クラス

# ✅ 抽象に依存
class UserService:
    def __init__(self, database: DatabaseInterface):
        self.db = database  # インターフェース

┌─────────────────────────────┐
│   Presentation Layer        │  UI, API Endpoints
├─────────────────────────────┤
│   Application Layer         │  Use Cases, Orchestration
├─────────────────────────────┤
│   Domain Layer              │  Business Logic, Entities
├─────────────────────────────┤
│   Infrastructure Layer      │  Database, External APIs
└─────────────────────────────┘

推奨パターン:
- API Gateway: 単一エントリーポイント
- Service Discovery: 動的サービス検出
- Circuit Breaker: 障害の連鎖防止
- Event Sourcing: イベント駆動
- CQRS: コマンドとクエリの分離

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

## 総合評価: B+

### 良好な点
✅ クリーンアーキテクチャの採用
✅ 適切な依存性注入
✅ レイヤー分離が明確

### 改善点

#### [HIGH] 循環依存の存在
**場所**: OrderService ↔ PaymentService
**影響**: テスタビリティの低下、デプロイの複雑化
**推奨**: イベント駆動アーキテクチャに変更

#### [MEDIUM] 単一責任原則違反
**場所**: UserController
**問題**: 認証、認可、ビジネスロジックが混在
**推奨**: 責務を分離

### アーキテクチャ提案

1. **イベント駆動への移行**: サービス間の結合度削減
2. **CQRS導入**: 読み書きの分離で性能向上
3. **キャッシュ層追加**: Redis で頻繁な読み取り最適化