アーキテクチャの変種
このドキュメントの目的
クリーンアーキテクチャ、ヘキサゴナルアーキテクチャ、オニオンアーキテクチャの関係性と共通の本質を理解することが目標です。
目次
3つのアーキテクチャ
ヘキサゴナルアーキテクチャ（Ports and Adapters）
┌─────────────────────────────────────────────┐
│ ヘキサゴナルアーキテクチャ │
├─────────────────────────────────────────────┤
│ 提唱者: Alistair Cockburn（2005年） │
│ │
│ ┌─────────────┐ │
│ ─────│ │───── │
│ │ │ Core │ │ │
│ │ Port│ (Domain) │Port │ │
│ │ │ │ │ │
│ ─────│ │───── │
│ └─────────────┘ │
│ │ │
│ Adapter │
│ │
│ 考え方: │
│ ├── アプリケーションは六角形 │
│ ├── Port = アプリケーションの入出力口 │
│ └── Adapter = 外部との変換 │
│ │
└─────────────────────────────────────────────┘
オニオンアーキテクチャ
┌─────────────────────────────────────────────┐
│ オニオンアーキテクチャ │
├─────────────────────────────────────────────┤
│ 提唱者: Jeffrey Palermo（2008年） │
│ │
│ ┌───────────────────┐ │
│ │ Infrastructure │ │
│ │ ┌─────────────┐ │ │
│ │ │ Application│ │ │
│ │ │ ┌───────┐ │ │ │
│ │ │ │Domain │ │ │ │
│ │ │ │ Model │ │ │ │
│ │ │ └───────┘ │ │ │
│ │ └─────────────┘ │ │
│ └───────────────────┘ │
│ │
│ 考え方: │
│ ├── 玉ねぎのように層が重なる │
│ ├── 中心にDomain Model │
│ └── 依存は 常に内側へ │
│ │
└─────────────────────────────────────────────┘
クリーンアーキテクチャ
┌─────────────────────────────────────────────┐
│ クリーンアーキテクチャ │
├─────────────────────────────────────────────┤
│ 提唱者: Robert C. Martin（2012年） │
│ │
│ ┌───────────────────────┐ │
│ │ Frameworks & Drivers │ │
│ │ ┌─────────────────┐ │ │
│ │ │Interface Adapters│ │ │
│ │ │ ┌─────────────┐ │ │ │
│ │ │ │ Use Cases │ │ │ │
│ │ │ │ ┌───────┐ │ │ │ │
│ │ │ │ │Entity │ │ │ │ │
│ │ │ │ └───────┘ │ │ │ │
│ │ │ └─────────────┘ │ │ │
│ │ └─────────────────┘ │ │
│ └───────────────────────┘ │
│ │
│ 考え方: │
│ ├── 同心円で層を表現 │
│ ├── 中心にEntities │
│ └── 依存ルールを明確化 │
│ │
└─────────────────────────────────────────────┘
共通の本質
3つとも同じことを言っている
┌─────────────────────────────────────────────┐
│ 共通する核心 │
├─────────────────────────────────────────────┤
│ │
│ 1. ビジネスロジックを中心に置く │
│ → 最も重要なものを守る │
│ │
│ 2. 依存は内側（中心）に向かう │
│ → 外側の変更が内側に影響しない │
│ │
│ 3. 技術的詳細は外側に置く │
│ → 差し替え可能にする │
│ │
└─────────────────────────────────────────────┘
図の形は違っても意味は同じ
ヘキサゴナル: 六角形の中心にCore
オニオン: 玉ねぎの中心にDomain
クリーン: 同心円の中心にEntity
全て「中心を守り、外側は差し替え可能」という同じ考え
インターフェースの使い方も同じ
┌─────────────────────────────────────────────┐
│ 3つとも同じ解決策を使う │
├─────────────────────────────────────────────┤
│ │
│ 問題: 内側が外側を使いたい │
│ （でも依存してはいけない） │
│ │
│ 解決: インターフェースを内側に置く │
│ 外側がそれを実装する │
│ │
│ ヘキサゴナル: Port（インターフェース） │
│ オニオン: Repository Interface │
│ クリーン: Gateway Interface │
│ │
│ 名前は違うが、やっていることは同じ │
│ │
└─────────────────────────────────────────────┘
違いはどこにあるか
名前と用語の違い
┌─────────────────────────────────────────────┐
│ 用語の対応 │
├─────────────────────────────────────────────┤
│ │
│ ヘキサゴナル オニオン クリーン │
│ ──────── ───────────────────────────────── │
│ Core Domain Model Entities │
│ Port Interface Gateway │
│ Adapter Infrastructure Adapter │
│ Application Use Cases │
│ │
└─────────────────────────────────────────────┘
強調点の違い
┌─────────────────────────────────────────────┐
│ 各アーキテクチャの強調点 │
├─────────────────────────────────────────────┤
│ │
│ ヘキサゴナル: │
│ └── 「外部との境界」を強調 │
│ PortとAdapterという明確な概念 │
│ 入力側と出力側を対称に扱う │
│ │
│ オニオン: │
│ └── 「依存の方向」を強調 │
│ 層の概念を明確化 │
│ Domain Modelの純粋さ │
│ │
│ クリーン: │
│ └── 「依存ルール」を強調 │
│ Use Caseを独立した層として明示 │
│ 実践的なガイドライン │
│ │
└─────────────────────────────────────────────┘
歴史的な関係
┌─────────────────────────────────────────────┐
│ 時系列 │
├─────────────────────────────────────────────┤
│ │
│ 2005年: ヘキサゴナル（Alistair Cockburn） │
│ ↓ 影響を受けて │
│ 2008年: オニオン（Jeffrey Palermo） │
│ ↓ 両方を統合・整理 │
│ 2012年: クリ ーン（Robert C. Martin） │
│ │
│ クリーンアーキテクチャは │
│ 先行する2つを参考に整理したもの │
│ │
└─────────────────────────────────────────────┘
どれを選ぶべきか
答え: どれでもいい
┌─────────────────────────────────────────────┐
│ 選び方 │
├─────────────────────────────────────────────┤
│ │
│ 本質は同じなので、どれを選んでも大差ない │
│ │
│ 選ぶ基準: │
│ ├── チームが馴染みのある用語 │
│ ├── 参考資料の多さ │
│ └── 説明のしやすさ │
│ │
│ 重要なのは: │
│ 「どのアーキテクチャを選ぶか」ではなく │
│ 「依存の方向を正しく保つ」こと │
│ │
└─────────────────────────────────────────────┘
現実のプロジェクトでは
┌─────────────────────────────────────────────┐
│ 実際の使われ方 │
├─────────────────────────────────────────────┤
│ │
│ 多くのプロジェクトでは: │
│ ├── 3つの考えをミックスして使う │
│ ├── プロジェクト固有の用語も混ざる │
│ └── 厳密に1つに従うことは稀 │
│ │
│ それで問題ない │
│ 大事なのは「本質を理解している」こと │
│ │
└─────────────────────────────────────────────┘
用語の混乱を恐れない
「ヘキサゴナルのPortと
クリーンのGatewayは同じですか？」
→ ほぼ同じ概念を指している
→ 厳密な定義より、チームでの共通理解が大事
→ 「内側が外側を知らないための仕組み」と理解していればOK
まとめ
3つのアーキテクチャの関係
┌──── ─────────────────────────────────────────┐
│ 本質は同じ │
├─────────────────────────────────────────────┤
│ │
│ ヘキサゴナル ≒ オニオン ≒ クリーン │
│ │
│ 共通する考え: │
│ ├── ビジネスロジックを中心に置く │
│ ├── 依存は内側に向かう │
│ └── 技術的詳細は外側で差し替え可能 │
│ │
│ 違いは: │
│ ├── 用語の違い │
│ ├── 強調点の違い │
│ └── 図の描き方の違い │
│ │
└─────────────────────────────────────────────┘
覚えておくべきこと
・図の形や用語に惑わされ ない
・本質は「依存の方向」
・どれを選んでも、正しく実践すれば同じ効果
・チームで共通理解を持つことが重要
次のステップ
- 過剰設計の罠 でアーキテクチャの適用判断を学ぶ