LESSON 25分

ストーリー

あなた
依存性の方向はわかったかな？
あ
あなた
はい。内側のドメインに向かって依存するんですよね。でも、ヘキサゴナルアーキテクチャ、クリーンアーキテクチャ、オニオンアーキテクチャ…いろんなパターンがあって混乱します
あ
高
高橋アーキテクト
実はね、それらは”同じ思想を異なる視点で表現したもの”なんだ。全体像を見れば、共通する本質が見えてくるよ

主要なアーキテクチャパターン

1. ヘキサゴナルアーキテクチャ（Ports & Adapters）

提唱者: Alistair Cockburn（2005年）

核心: アプリケーションを「Port（インターフェース）」と「Adapter（実装）」で外部と接続する。

              ┌─────────────┐
   HTTP ──→  │  Port (in)  │
              │             │
              │  ドメイン    │
              │             │
              │  Port (out) │  ──→ DB
              └─────────────┘

2. オニオンアーキテクチャ

提唱者: Jeffrey Palermo（2008年）

核心: 同心円状の層構造。内側のドメインモデルを中心に、外側に向かって依存が広がる。

┌────────────────────────────┐
│ Infrastructure             │
│  ┌──────────────────────┐  │
│  │ Application Services │  │
│  │  ┌────────────────┐  │  │
│  │  │ Domain Services│  │  │
│  │  │  ┌──────────┐  │  │  │
│  │  │  │  Domain  │  │  │  │
│  │  │  │  Model   │  │  │  │
│  │  │  └──────────┘  │  │  │
│  │  └────────────────┘  │  │
│  └──────────────────────┘  │
└────────────────────────────┘

3. クリーンアーキテクチャ

提唱者: Robert C. Martin（Uncle Bob, 2012年）

核心: 4つの同心円。依存性ルール（Dependency Rule）を明確に定義。

┌──────────────────────────────────┐
│ Frameworks & Drivers             │
│  ┌────────────────────────────┐  │
│  │ Interface Adapters         │  │
│  │  ┌──────────────────────┐  │  │
│  │  │ Application Business │  │  │
│  │  │  ┌────────────────┐  │  │  │
│  │  │  │  Enterprise   │  │  │  │
│  │  │  │  Business     │  │  │  │
│  │  │  └────────────────┘  │  │  │
│  │  └──────────────────────┘  │  │
│  └────────────────────────────┘  │
└──────────────────────────────────┘

3つのパターンの共通点

共通原則説明
ドメイン中心ビジネスロジックが最も内側にある
依存の方向外側から内側に向かう
インターフェースによる分離境界をインターフェースで定義する
技術の交換可能性インフラ層の差し替えが容易
// どのパターンでも、この構造は共通
// 1. ドメインにインターフェースを定義
interface OrderRepository {
  findById(id: string): Promise<Order>;
  save(order: Order): Promise<void>;
}

// 2. ユースケースはインターフェースに依存
class CreateOrderUseCase {
  constructor(private repo: OrderRepository) {}
}

// 3. インフラがインターフェースを実装
class PrismaOrderRepository implements OrderRepository {
  // ...
}

パターンの違い

観点ヘキサゴナルオニオンクリーン
メタファー六角形（ポート）玉ねぎ（層）同心円（4層）
強調点外部との接続方法ドメインモデルの保護依存性ルールの厳密さ
層の数明示的に定めない4層4層
命名Port / AdapterDomain / Service / InfraEntity / UseCase / Adapter / FW
実用面外部連携が多いシステム向きドメインが複雑なシステム向き汎用的

今月学ぶパターンの関係

ヘキサゴナル ───── 外部との接続方法にフォーカス
    │                  ↓
    │            「Portを通じてAdapterと繋がる」
    │
クリーン ─────── 内部の層構造にフォーカス
    │                  ↓
    │            「4つの同心円と依存性ルール」
    │
DDD ──────────── ドメインモデリングにフォーカス
                       ↓
                 「Bounded ContextとAggregateで
                  複雑なドメインを整理する」

これらは対立するものではなく、組み合わせて使うものです。

// 実際のプロジェクトでは3つを組み合わせる
src/
├── domain/                    // DDD + クリーンのEntity層
│   ├── order/                 // Bounded Context
│   │   ├── Order.ts           // Aggregate Root
│   │   ├── OrderItem.ts       // Entity
│   │   └── Money.ts           // Value Object
│   └── ports/                 // ヘキサゴナルのPort
│       ├── in/OrderUseCase.ts
│       └── out/OrderRepository.ts
├── application/               // クリーンのUseCase層
│   └── CreateOrderUseCase.ts
└── adapters/                  // ヘキサゴナルのAdapter
    ├── in/OrderController.ts
    └── out/PrismaOrderRepository.ts

どのパターンを選ぶべきか

状況推奨
小規模・シンプルレイヤードアーキテクチャで十分
外部連携が多いヘキサゴナルアーキテクチャ
テスタビリティ重視クリーンアーキテクチャ
複雑なビジネスドメインDDD + ヘキサゴナル or クリーン
マイクロサービスDDD（Bounded Context）で分割

まとめ

ポイント内容
3つのパターンヘキサゴナル、オニオン、クリーン
共通点ドメイン中心、依存は内向き、インターフェースで分離
違いメタファーと強調点が異なる
実践3つを組み合わせて使うのが一般的

チェックリスト

  • 3つのアーキテクチャパターンの特徴を説明できる
  • 共通する4つの原則を理解した
  • パターンの違いを把握した
  • 状況に応じたパターン選択の指針を理解した

次のステップへ

次は「アーキテクチャ判断の記録（ADR）」を学びます。なぜそのアーキテクチャを選んだのか、判断の根拠を記録する方法を身につけましょう。

推定読了時間: 25分