Skip to content

ADR-0003: DDDアーキテクチャの採用

ドメイン駆動設計（DDD）に基づく3層アーキテクチャを採用する

日付: 2025-07-31

ステータス

2025-07-31 提案されました 2025-07-31 受け入れられました

コンテキスト

ぷよぷよゲーム開発において、以下の課題に対応するアーキテクチャ設計が必要でした：

ビジネス要件

  • 複雑なゲームルール: ぷよ消去、連鎖、スコア計算の複雑性
  • 段階的開発: 8つのイテレーションでの機能追加
  • 保守性確保: 長期的な機能拡張と改修
  • テスタビリティ: TDD実践のための設計

技術的課題

  • 関心事の分離: UI、ビジネスロジック、技術的詳細の分離
  • 依存関係管理: モジュール間の適切な依存関係
  • 拡張性: 新機能追加時の影響範囲最小化
  • 再利用性: コンポーネントの再利用可能性

検討したアーキテクチャ

  • MVC: Model-View-Controller
  • MVP: Model-View-Presenter
  • MVVM: Model-View-ViewModel
  • DDD: Domain-Driven Design

決定

ドメイン駆動設計（DDD）に基づく3層アーキテクチャを採用する

アーキテクチャ構成

src/
├── domain/              # ドメイン層
│   ├── model/          # エンティティ・値オブジェクト
│   └── type/           # ドメインサービス
├── application/         # アプリケーション層
│   └── GameController  # ユースケース・オーケストレーション
└── infrastructure/     # インフラストラクチャ層
    ├── input/          # 入力処理
    └── rendering/      # 描画処理

採用理由

  1. ビジネスロジック中心設計
  2. ゲームルールの明確なモデリング
  3. ドメインエキスパートとの共通言語

  4. ビジネス価値の最大化

  5. 優れた保守性

  6. 明確な責務分離
  7. 変更影響範囲の限定

  8. 単体テストの容易性

  9. 拡張性の確保

  10. 新機能追加時の影響最小化
  11. オープン・クローズドの原則

  12. 既存コードの安定性

  13. テスタビリティ

  14. 各層の独立テスト
  15. ドメインロジックの純粋性
  16. モックの効果的活用

層の責務定義

ドメイン層

  • エンティティ: ゲーム、ゲームフィールド
  • 値オブジェクト: ぷよ、ぷよペア、位置
  • ドメインサービス: ゲーム状態、ぷよ色
  • ルール: ビジネスロジックの集約

アプリケーション層

  • ユースケース: ゲーム操作の調整
  • オーケストレーション: 複数ドメインの連携
  • 入出力調整: UI↔ドメイン変換

インフラストラクチャ層

  • 技術的実装: Canvas描画、キーボード入力
  • 外部システム: イベント処理、DOM操作
  • フレームワーク: Vite、Vitest連携

影響

ポジティブな影響

  1. コード品質の向上
  2. ビジネスロジックの集約
  3. 単一責任原則の遵守

  4. 高い凝集度の実現

  5. 開発効率の向上

  6. TDD実践の促進
  7. 並行開発の可能性

  8. デバッグ効率の改善

  9. 保守性の向上

  10. 変更影響範囲の明確化
  11. テストの安定性

  12. リファクタリングの安全性

  13. 拡張性の確保

  14. 新機能追加の容易性
  15. 既存機能の安定性
  16. アーキテクチャの一貫性

ネガティブな影響

  1. 初期複雑性
  2. 層分離による複雑さ
  3. ファイル数の増加

  4. 設計理解の学習コスト

  5. オーバーエンジニアリング

  6. 小規模プロジェクトでの過剰設計
  7. 抽象化のコスト

  8. 開発速度の初期低下

  9. チーム習熟コスト

  10. DDD概念の理解
  11. 設計パターンの習得
  12. コードレビューの複雑化

コンプライアンス

この決定の遵守を確認する方法：

構造的検証

  1. ディレクトリ構造 

    # 層構造の確認
find src -type d -name "domain"
find src -type d -name "application"  
find src -type d -name "infrastructure"

  2. 依存関係検証 

    # 依存関係の方向性確認
# ドメイン層は他層に依存しない
grep -r "import.*infrastructure" src/domain/ && echo "依存関係違反"
grep -r "import.*application" src/domain/ && echo "依存関係違反"

  3. ファイル配置確認

  4. ドメインモデル: src/domain/model/
  5. ビジネスロジック: src/domain/
  6. ユースケース: src/application/
  7. 技術実装: src/infrastructure/

設計品質検証

  1. 単体テスト比率
  2. ドメイン層テストカバレッジ: 95%以上
  3. 各層の独立テスト実行可能性

  4. モックを使わないドメインテスト

  5. 結合度測定

  6. 層間の結合度最小化
  7. インターフェース経由の依存

  8. 循環依存の排除

  9. 凝集度評価

  10. 各クラスの単一責任性
  11. ドメイン概念の適切な抽象化
  12. ビジネスルールの集約

備考

著者

プロジェクトチーム

関連決定

  • ADR-0001: TypeScriptの採用（型安全な設計支援）
  • ADR-0002: Vitestの採用（層別テスト戦略）
  • ADR-0004: Canvas APIの採用（インフラ層技術選択）

参考資料

実装例

ドメインモデル例

// src/domain/model/Game.ts
export class Game {
  private field: GameField
  private currentPuyo: PuyoPair | null
  private state: GameState

  // ビジネスルールの実装
  movePuyo(dx: number, dy: number): boolean {
    // ドメインロジック
  }
}

アプリケーション層例

// src/application/GameController.ts
export class GameController {
  constructor(
    private game: Game,
    private inputHandler: InputHandler,
    private renderer: GameRenderer
  ) {}

  // ユースケースの調整
  update(): void {
    this.handleInput()
    this.game.update()
    this.render()
  }
}

成果指標

指標 目標値 実績値
テストカバレッジ 90% 95%
循環依存数 0 0
平均クラス責務数 1 1.2
層間結合度 最小 最小

将来の検討事項

  • マイクロサービス化の可能性
  • CQRS（Command Query Responsibility Segregation）導入
  • イベントソーシングの適用検討