ADR-001: アーキテクチャ選定¶
ステータス¶
採用
背景¶
ぷよぷよゲームシステムの開発において、アプリケーションのアーキテクチャパターンを決定する必要がある。要件分析の結果、複雑なゲームロジック（連鎖、消去判定、重力適用）を持つシステムであり、将来的な機能拡張（マルチプレイヤー、AI対戦等）も想定される。
検討事項¶
アーキテクチャ選定基準¶
CLAUDE.local.mdのアーキテクチャ選定フローに基づく：
- 業務領域カテゴリー: 中核の業務領域（複雑なゲームロジック）
- 金額・分析・監査記録: 不要（ゲームのため）
- 永続化モデル: 単一（ローカルストレージのみ）
候補アーキテクチャ¶
1. レイヤードアーキテクチャ (3層)¶
- メリット: 理解しやすい、実装が簡単
- デメリット: ビジネスロジックとデータアクセスの結合、テスタビリティの低さ
- 適用: 単純なCRUDアプリケーション
2. ヘキサゴナルアーキテクチャ（ポートとアダプター）¶
- メリット: ドメインロジックの独立性、高いテスタビリティ、依存性逆転
- デメリット: 初期実装の複雑さ、学習コスト
- 適用: 複雑なビジネスロジック、外部システム統合
3. クリーンアーキテクチャ¶
- メリット: 層の明確な分離、高い保守性
- デメリット: 過度な抽象化、小規模プロジェクトには重い
- 適用: 大規模・長期プロジェクト
決定¶
ヘキサゴナルアーキテクチャ（ポートとアダプター）を採用する
理由¶
- ドメインロジックの複雑さ:
- ぷよの連鎖検出・消去ロジック
- 重力計算・衝突判定
-
スコア計算・ボーナス適用
-
テスタビリティの重要性:
- TDD開発サイクルの採用
- ドメインロジックの単体テスト
-
外部依存からの分離
-
将来拡張への対応:
- 新しい入力デバイス対応（タッチ、ゲームパッド）
- 永続化方式の変更（クラウド保存）
-
新機能追加（AI、ネットワーク対戦）
-
適切なスケール:
- 中規模プロジェクトに適合
- 過度な抽象化を避けつつ、柔軟性を確保
アーキテクチャ構造¶
┌─────────────────┐ ┌─────────────────┐
│ Presentation │ │ Infrastructure │
│ Layer │ │ Layer │
│ │ │ │
│ - GameComponent │ │ - LocalStorage │
│ - InputHandler │ │ - AnimationAPI │
│ - BoardRenderer │ │ - SoundAPI │
└─────────┬───────┘ └─────────┬───────┘
│ │
▼ ▼
┌─────────────────┐ ┌─────────────────┐
│ Application │ │ Ports │
│ Layer │ │ (Interfaces) │
│ │ │ │
│ - GameService │◄──►│ - GamePort │
│ - ScoreService │ │ - StoragePort │
│ - InputService │ │ - SoundPort │
└─────────┬───────┘ └─────────────────┘
│
▼
┌─────────────────┐
│ Domain │
│ Layer │
│ │
│ - Game │
│ - Field │
│ - Puyo │
│ - Chain │
│ - Score │
└─────────────────┘
結果¶
- ドメイン層の独立性: 外部技術に依存しない純粋なビジネスロジック
- 高いテスタビリティ: モックを使用した効率的な単体テスト
- 柔軟な技術選択: アダプターパターンによる技術変更への対応
- 明確な責任分離: 各層の役割が明確で保守しやすい
注意点¶
- 初期実装コスト: 単純なレイヤードアーキテクチャより実装が複雑
- チーム学習: ヘキサゴナルアーキテクチャの理解が必要
- 過度な抽象化回避: 必要以上にポートを作らない
関連ADR¶
- ADR-002: フロントエンド技術スタック選定
- ADR-003: 状態管理戦略
- ADR-004: テスト戦略
日付: 2025-08-12
作成者: Claude Code
レビュー者: プロジェクトチーム
次回見直し: 2025-11-12（3ヶ月後）