ドメインモデルを最内層に置き、外側のレイヤが内側に依存する同心円型アーキテクチャ。Jeffrey Palermo が 2008 年のブログ連載で提唱した。
概要
伝統的な 3 層アーキテクチャ（UI → Business → Data Access）では ビジネス層がデータアクセス層に依存 してしまい、DB 技術がドメインに漏れる構造になる。オニオンアーキテクチャはこの依存方向を反転させ、 同心円の中心にドメインモデルを置き、すべての依存が中心を向く ように整理する。
レイヤ構成
┌─────────────────────────────────────┐
│ Infrastructure / UI / Tests │
│ ┌───────────────────────────────┐ │
│ │ Application Services │ │
│ │ ┌─────────────────────────┐ │ │
│ │ │ Domain Services │ │ │
│ │ │ ┌───────────────────┐ │ │ │
│ │ │ │ Domain Model │ │ │ │
│ │ │ │ （Entity / VO） │ │ │ │
│ │ │ └───────────────────┘ │ │ │
│ │ └─────────────────────────┘ │ │
│ └───────────────────────────────┘ │
└─────────────────────────────────────┘| 層 | 責務 |
|---|---|
| Domain Model | エンティティ・値オブジェクト・集約。最も安定 |
| Domain Services | エンティティに置きにくいドメインロジック |
| Application Services | ユースケース調整・トランザクション境界 |
| Infrastructure / UI / Tests | DB 実装・REST 入口・外部 API・テストランナー |
核となる原則
| 原則 | 内容 |
|---|---|
| 依存方向は内向き | 外側のレイヤだけが内側を参照できる |
| インターフェースは内側で定義 | リポジトリ I/F はドメインに置き、実装は外側 |
| 中心は技術に無関係 | ドメインモデルにフレームワーク import を入れない |
| テスト容易性 | 外側を差し替えてドメインを単体テストできる |
3 層アーキテクチャとの違い
| 観点 | 3 層 | オニオン |
|---|---|---|
| 中心 | UI または DB | ドメインモデル |
| ビジネス層 → データ層 | あり | 禁止（逆転） |
| インターフェース定義先 | データ層 | ドメイン層 |
| ドメインの純度 | 低い（DB 由来の制約が混入） | 高い |
ヘキサゴナル / クリーンとの関係
| 名称 | 提唱者 | 強調点 |
|---|---|---|
| ヘキサゴナル | Alistair Cockburn (2005) | ポートとアダプタの対称性 |
| オニオン | Jeffrey Palermo (2008) | 同心円のレイヤ構造 |
| クリーン | Robert C. Martin (2012) | 依存方向のルールを明文化 |
3 者は本質的に同型で、「ドメインを中心に、外側が内側に依存する」原則を別の図と語彙で説明したもの。オニオンの貢献は同心円という直感的な図示にある。
アンチパターン
- 同心円の儀式化 — 各レイヤに DTO を作って Mapper を増やすだけで価値が出ない
- Application Services の肥大化 — ドメインに置くべきロジックが Application 層に流れて Domain が空洞化
- Infrastructure からの逆参照 — フレームワークの都合でドメインに属性アノテーションが侵食する
関連記事
- 開発手法ガイド：概要 — DDD 系列での位置づけ
関連用語
- ヘキサゴナルアーキテクチャ — オニオンと同型の先行整理
- クリーンアーキテクチャ — オニオンと同型の後発整理
- SOLID 原則 — 特に DIP がオニオンの根拠
- DDD — オニオンが想定するドメイン設計
- リポジトリパターン — ドメインと外側を分離する実装手段
- SoC（関心の分離） — オニオンの上位原則