アプリケーション本体を「ポート」と「アダプタ」で外界から切り離し、入出力技術を後から差し替え可能に保つアーキテクチャスタイル。Alistair Cockburn が 2005 年に提唱した。「ポート＆アダプタ」「クリーンアーキテクチャ」「オニオンアーキテクチャ」と本質的に同型の発想。
核となる考え方
アプリケーションコア（ビジネスロジック）は どんな入出力技術にも依存しない 純粋なオブジェクト群として作る。外部とのやり取りは「ポート（インターフェース）」を通じて行い、具体的な技術は「アダプタ」が実装する。
「ヘキサゴナル（六角形）」と呼ぶ理由
図示するときに六角形を使うのは 入出力チャネルが複数あること を示すため。 6 という数に意味はない （UI / API / バッチ / DB / 外部 API / キュー など複数あるという象徴）。
ポートとアダプタの分類
| 分類 | 役割 | 例 |
|---|---|---|
| ドライビングポート | アプリを呼び出す側のインターフェース | PlaceOrderUseCase |
| ドライビングアダプタ | 上記ポートを呼び出す具象 | REST コントローラ / CLI / バッチ |
| ドリブンポート | アプリが外界に依頼する側のインターフェース | OrderRepository / MailSender |
| ドリブンアダプタ | 上記ポートを実装する具象 | PostgreSQL 実装 / SMTP 実装 |
何が嬉しいのか
| 利点 | 中身 |
|---|---|
| 技術交換が容易 | DB を PostgreSQL → DynamoDB に替えてもコアは無傷 |
| テストが速い | アダプタをインメモリ実装に差し替えてユースケースを単体テスト可能 |
| ビジネスロジックの純度 | コアにフレームワークの import が混入しない |
| AI 駆動開発との相性 | 影響範囲がアダプタ層に閉じるため、AI 生成コードのレビュー範囲を絞れる |
クリーン / オニオン / ヘキサゴナルの関係
| 名称 | 提唱者 | 特徴 |
|---|---|---|
| ヘキサゴナル | Alistair Cockburn (2005) | 「ポート＆アダプタ」を強調 |
| オニオン | Jeffrey Palermo (2008) | レイヤを同心円で表現 |
| クリーン | Robert C. Martin (2012) | 依存方向のルールを明文化 |
いずれも 「ドメインを中心に置き、外側のレイヤが内側に依存する」 同じ原則を別の図で説明したもの。
アンチパターン
- コアにフレームワーク依存が漏れる —
using Microsoft.EntityFrameworkCore;がドメインクラスに登場 - アダプタの肥大化 — ビジネスロジックをアダプタに書いてしまい、コアが空洞化
- ポートが過剰に細かい — メソッド 1 つだけのインターフェースが乱立し、見通しが悪化
SOLID との関係
ヘキサゴナルは DIP（依存性逆転） をアーキテクチャ全体に適用した姿。コアが詳細（DB・API）に依存するのではなく、詳細がコアの定義したインターフェースに依存する向きを徹底する。
関連記事
- 開発手法ガイド：概要 — DDD 系列での位置づけ
関連用語
- DDD — ヘキサゴナルと相性の良いドメイン設計手法
- クリーンアーキテクチャ — 同型の後発整理（依存方向ルールを明文化）
- オニオンアーキテクチャ — 同型の先行整理（同心円表現）
- リポジトリパターン — ドリブンポートの代表例
- SOLID 原則 — 特に DIP の全面適用
- オブジェクト指向 — 階層分離を支える基本パラダイム
- SoC（関心の分離） — ヘキサゴナルが体現する原則
- CQRS — ヘキサゴナル内で書き込み/読み取りポートを分ける拡張