依存方向を「外側 → 内側」に固定し、ビジネスルール（ドメイン層）をフレームワーク・DB・UI から守るアーキテクチャ。Robert C. Martin（Uncle Bob）が 2012 年のブログ記事で整理し、後に同名書籍（2017）で体系化した。
概要
クリーンアーキテクチャは新発明ではなく、 ヘキサゴナルアーキテクチャ・オニオンアーキテクチャ・DCI など先行する複数の整理を統合し、依存方向のルールを明文化したもの。同心円の図で表現されることが多い。
4 つの同心円
┌──────────────────────────────────┐
│ Frameworks & Drivers │
│ （Web / DB / 外部 API / UI） │
│ ┌────────────────────────────┐ │
│ │ Interface Adapters │ │
│ │ （Controller / Presenter / │ │
│ │ Gateway） │ │
│ │ ┌──────────────────────┐ │ │
│ │ │ Use Cases │ │ │
│ │ │ （アプリ固有の業務） │ │ │
│ │ │ ┌────────────────┐ │ │ │
│ │ │ │ Entities │ │ │ │
│ │ │ │ （企業横断の │ │ │ │
│ │ │ │ 業務ルール） │ │ │ │
│ │ │ └────────────────┘ │ │ │
│ │ └──────────────────────┘ │ │
│ └────────────────────────────┘ │
└──────────────────────────────────┘| 層 | 責務 | 例 |
|---|---|---|
| Entities | 企業横断で再利用できる業務ルール | Money, Account |
| Use Cases | アプリケーション固有のユースケース | PlaceOrderInteractor |
| Interface Adapters | 外と内のデータ変換 | Controller / Presenter / Gateway |
| Frameworks & Drivers | フレームワーク・I/O 技術 | Web フレームワーク / ORM / DB ドライバ |
依存性のルール
唯一にして最重要のルール: ソースコードの依存方向は 常に外から内へ。内側のレイヤは外側の名前を一切知らない。
| 良い例 | 悪い例 |
|---|---|
Entity が interface UserRepository を定義し、外側が実装 | Entity が import org.springframework... |
Use Case が抽象 OrderRepository を呼ぶ | Use Case が EntityManager.persist() を直呼び |
| Controller が Use Case を呼び、結果を Presenter で表示 | Controller がドメインルールを直接持つ |
入力と出力の分離
クリーンアーキテクチャは Use Case の入出力を Input Boundary / Output Boundary という別インターフェースで切り出す。これにより、UI 層（Presenter）が Use Case の内部に依存せず、テスト時のモック差し替えが容易になる。
ヘキサゴナル / オニオンとの関係
| 名称 | 提唱者 | 強調点 |
|---|---|---|
| ヘキサゴナル | Alistair Cockburn (2005) | ポートとアダプタの対称性 |
| オニオン | Jeffrey Palermo (2008) | 同心円のレイヤ構造 |
| クリーン | Robert C. Martin (2012) | 依存方向のルールを明文化 |
3 者は本質的に同型。「ドメインを中心に、外側が内側に依存する」原則を別の図と語彙で説明したもの。新規プロジェクトで「どれを採用するか」より「依存方向を内向きに固定する」ことの方が重要。
アンチパターン
- クリーン教の儀式化 — 4 層全部に DTO を作って Mapper を増やすだけで価値が出ない
- Entity が貧弱 — Use Case にロジックが集まり、Entity が単なるデータバッグになる
- 層を跨ぐショートカット — Controller から直接 Repository を呼んで Use Case を飛ばす
関連記事
- 開発手法ガイド：概要 — DDD 系列での位置づけ
関連用語
- ヘキサゴナルアーキテクチャ — 依存方向ルールの先行整理
- オニオンアーキテクチャ — 同心円表現の先行整理
- SOLID 原則 — 特に DIP がクリーンアーキテクチャの土台
- DDD — クリーンアーキテクチャと相性の良いドメイン設計
- リポジトリパターン — Use Case と DB を分離する実装手段
- SoC（関心の分離） — クリーンアーキテクチャの上位原則