六角形アーキテクチャ（ポートとアダプター）

解決する課題

従来の層状アーキテクチャ（UI → ビジネス層 → DB層）では、ドメインロジックがインフラ（フレームワーク・DB・外部API）に依存してしまいやすい。ドメインに UI やフレームワークの概念が混入すると、テストが困難になり、技術の差し替えが難しくなる。

概念

Alistair Cockburn が提唱したアーキテクチャスタイル。ドメインを中心（内側） に置き、外部のすべてのアクター（UI、DB、メッセージキュー、外部API）をアダプター（外側） で接続する。

        [HTTP]  [CLI]  [テスト]
           ↓       ↓       ↓
      ┌─────────────────────┐
      │   ポート（インターフェース）│
      │  ┌─────────────────┐ │
      │  │   ドメインモデル   │ │
      │  │  （純粋なロジック） │ │
      │  └─────────────────┘ │
      │   ポート（インターフェース）│
      └─────────────────────┘
           ↓       ↓       ↓
        [DB] [メッセージキュー] [外部API]

• ポート: ドメインが外部に公開するインターフェース（抽象）
• アダプター: ポートの具体的な実装（HTTP コントローラ、DB リポジトリ、メッセージプロデューサー）

なぜ重要か

• ドメインが フレームワーク・DBに依存しない → テストが容易
• アダプターを差し替えるだけで別の技術に移行できる（DB を MySQL → PostgreSQL へ）
• ドメインロジックを理解するために UI の知識が不要になる

IDDD における位置づけ

Vernon は六角形アーキテクチャを DDD の「デフォルトアーキテクチャ」として推薦している。ドメインモデルをインフラから守ることが、長期的なモデルの純粋性を保証する。

他の選択肢（CQRS、イベント駆動）と組み合わせることも多い。

依存の方向

重要な原則：外側が内側に依存する。内側は外側を知らない。

✅ DBアダプター → リポジトリインターフェース（ドメイン）
❌ ドメイン → DB（Hibernate等）の具体クラス

依存性逆転の原則（DIP）をアーキテクチャレベルで実現したもの。

適用例

アクター	ポート（インターフェース）	アダプター（実装）
HTTPリクエスト	ApplicationService	REST コントローラ
ユニットテスト	Repository	In-Memory リポジトリ
本番DB	Repository	JPA / SQLAlchemy
メッセージ配信	DomainEventPublisher	RabbitMQ / Kafka

関連概念

• → アプリケーションサービス（外部からドメインへの入り口）
• → リポジトリ（ポートとアダプターの典型例）
• → CQRS（六角形との組み合わせパターン）