アーキテクチャパターン

オニオンアーキテクチャおにおんあーきてくちゃ

レイヤードアーキテクチャドメイン駆動設計依存性逆転の原則クリーンアーキテクチャ関心の分離ポートアンドアダプター

オニオンアーキテクチャについて教えて

簡単に言うとこんな感じ！

タマネギみたいに層が重なったソフトウェアの設計図だよ！一番大事なビジネスルールを中心に置いて、データベースや画面などの「外の都合」に振り回されないようにする考え方なんだ。外側の層を替えても中身に影響しないのが最大の強みだよ！

オニオンアーキテクチャとは

オニオンアーキテクチャとは、ソフトウェアを「タマネギの断面」のように同心円状の層で設計する考え方です。2008年にJeffrey Palermoが提唱しました。最大の特徴は「依存の方向を常に内側へ向ける」というルールで、中心にあるビジネスロジックが、データベースやUIといった外部の技術的な都合に依存しないように設計します。

従来のレイヤードアーキテクチャでは「UI → ビジネスロジック → データベース」という順で依存が流れ、データベースの都合がビジネスロジックに影響してしまいがちでした。オニオンアーキテクチャはこの問題を解決するために、依存性逆転の原則（DIP）を徹底適用し、「外側の層が内側の層に依存する」方向に統一します。

ビジネスパーソンの視点で言えば、「システムのコアとなるルールを守りながら、将来データベースを替えたり、APIを追加したりしても大規模な改修が不要になる」設計思想です。長期的な保守コストを下げ、変化に強いシステムを作るための重要なアーキテクチャパターンです。

層の構造と責務

オニオンアーキテクチャは一般的に以下の4層で構成されます。内側ほど「変わりにくいもの」、外側ほど「変わりやすいもの」が配置されます。

層（内→外）	別名	役割	具体例
① ドメインモデル	コア	ビジネスの概念・ルールそのもの	「注文」「顧客」「在庫」などのクラス
② ドメインサービス	—	複数のドメインモデルをまたぐビジネスロジック	「注文確定処理」「在庫引当ロジック」
③ アプリケーションサービス	ユースケース	ユーザーの操作に対応する処理の流れ	「商品を注文する」「レポートを出力する」
④ インフラストラクチャ / UI	外側	データベース・API・画面など技術的な実装	MySQLアクセス、REST API、Webフォーム

最重要ルール：依存は必ず内向き

  ┌─────────────────────────────┐
  │  ④ インフラ / UI（外側）   │
  │   ┌─────────────────────┐  │
  │   │  ③ アプリケーション │  │
  │   │  ┌───────────────┐ │  │
  │   │  │ ② ドメイン    │ │  │
  │   │  │ サービス      │ │  │
  │   │  │ ┌───────────┐│ │  │
  │   │  │ │① ドメイン ││ │  │
  │   │  │ │  モデル   ││ │  │
  │   │  │ └───────────┘│ │  │
  │   │  └───────────────┘ │  │
  │   └─────────────────────┘  │
  └─────────────────────────────┘
  依存の向き：→ 外から内へのみ

外側の層は内側の層を知っていいが、内側の層は外側の層を知ってはいけない。これがオニオンアーキテクチャの絶対ルールです。

「ポート」と「アダプター」の概念

内側の層が外側（データベース等）を直接呼び出さないために、インターフェース（ポート）という抽象的な窓口を定義します。実際のデータベースアクセスなどの実装（アダプター）は外側の層に置き、内側からは「どう実装されているかを知らなくてよい」状態にします。

歴史と背景

2008年 — Jeffrey PalermoがブログでOnion Architectureを提唱。レイヤードアーキテクチャの「データベース中心設計」への反省から生まれた
2003年頃 — Eric Evansが「ドメイン駆動設計（DDD）」を提唱。ビジネスロジックをコアに据える思想がオニオンアーキテクチャの土台となった
2005年 — Alistair Cockburnが「ヘキサゴナルアーキテクチャ（ポート&アダプター）」を提唱。オニオンと問題意識を共有する兄弟的な設計パターン
2012年 — Robert C. Martin（Uncle Bob）が「クリーンアーキテクチャ」を発表。オニオン・ヘキサゴナルの考え方を統合・整理した
2010年代後半〜 — マイクロサービスの普及とともに、各サービス内の設計にオニオン/クリーンアーキテクチャを適用するケースが急増

類似アーキテクチャとの比較

オニオンアーキテクチャは「関心の分離」を目指す複数のアーキテクチャパターンと兄弟関係にあります。

観点	レイヤード	オニオン	クリーンアーキテクチャ	ヘキサゴナル
登場年	1990年代〜	2008年	2012年	2005年
中心にあるもの	データベース	ドメインモデル	エンティティ	アプリケーション
依存の方向	上→下	外→内	外→内	外→内
テスト容易性	△	○	◎	○
学習コスト	低	中	高	中
向いている規模	小〜中	中〜大	大〜複雑	中〜大

実務での使いどころ

向いているケース：ビジネスルールが複雑で、将来的にデータベースや外部サービスの変更が想定されるシステム（基幹系・EC・SaaS）
向いていないケース：CRUD中心のシンプルな管理画面、プロトタイプ、短命なバッチ処理