ソフトウェアアーキテクチャを学ぶ中で、「オニオンアーキテクチャ」「クリーンアーキテクチャ」「ヘキサゴナルアーキテクチャ」「レイヤードアーキテクチャ」といった複数の設計パターンに出会い、それぞれの違いが把握しにくいと感じる方は多いでしょう。
本記事では、オニオンアーキテクチャとクリーンアーキテクチャの違い・共通点・使い分けを中心に、関連する設計パターンも交えながら詳しく解説していきます。
オニオンアーキテクチャとクリーンアーキテクチャは「同じ思想の異なる表現」
それではまず、オニオンアーキテクチャとクリーンアーキテクチャの根本的な関係について解説していきます。
結論から述べると、オニオンアーキテクチャとクリーンアーキテクチャは同じ根本的な設計思想を持つ非常に似た設計パターンであり、表現や用語が異なるだけで本質的な原則は共通しています。
両者ともに「ドメイン（ビジネスロジック）を中心に置き、外部の技術的詳細から保護する」という思想と「依存関係は外側から内側への一方向のみ」という原則を共有しています。
オニオンアーキテクチャとクリーンアーキテクチャの共通原則：
①ビジネスロジックを中心（最も内側）に配置する
②依存関係は外側のレイヤーから内側のレイヤーへの一方向のみ
③フレームワーク・DB・UIに依存しない独立したビジネスロジック
④インターフェース（抽象）を通じた依存関係の逆転（DIP）
クリーンアーキテクチャとは
クリーンアーキテクチャは、Robert C. Martin（Uncle Bob）によって2012年に提唱された設計パターンです。
中心から外側に向かってエンティティ（Entities）・ユースケース（Use Cases）・インターフェースアダプター（Interface Adapters）・フレームワーク＆ドライバー（Frameworks & Drivers）という4つの同心円状レイヤーで構成されます。
「フレームワーク独立性」「テスタビリティ」「UI独立性」「データベース独立性」「外部エージェント独立性」という5つの特性をアーキテクチャの目標として明示しているのが特徴でしょう。
| 比較項目 | オニオンアーキテクチャ | クリーンアーキテクチャ |
|---|---|---|
| 提唱者・年 | Jeffrey Palermo（2008年） | Robert C. Martin（2012年） |
| 中心概念 | ドメインモデル | エンティティ（ビジネスルール） |
| レイヤー数 | 4層程度（柔軟） | 4層（明確に定義） |
| DDDとの親和性 | 高（DDD前提の設計） | 中（DDDと組み合わせ可能） |
| 図の形状 | 同心円状（玉ねぎ型） | 同心円状（クリーン円） |
主な違い：レイヤーの定義と粒度
オニオンアーキテクチャとクリーンアーキテクチャの主な違いの一つは、レイヤーの定義と粒度にあります。
オニオンアーキテクチャはDDDの概念（エンティティ・リポジトリインターフェース・ドメインサービスなど）を前提としたレイヤー定義を持ちます。
クリーンアーキテクチャはDDDに限定しない、より汎用的なレイヤー定義を採用しており、特に「ユースケース」レイヤーを明確に定義してアプリケーション固有のビジネスルールと企業全体のビジネスルールを分離している点が特徴的でしょう。
ヘキサゴナルアーキテクチャとの比較
続いては、ヘキサゴナルアーキテクチャとの比較を確認していきます。
ヘキサゴナルアーキテクチャ（Hexagonal Architecture）もオニオン・クリーンと同じ思想を持つ設計パターンです。
ヘキサゴナルアーキテクチャの概要
ヘキサゴナルアーキテクチャは、Alistair Cockburnによって提唱された設計パターンで、「ポートとアダプター（Ports and Adapters）」アーキテクチャとも呼ばれます。
アプリケーションの中心に「コア（ドメインロジック）」を置き、その周囲に「ポート（インターフェース）」と「アダプター（具体的な実装）」を配置します。
「プライマリポート（駆動側）」：UIやAPIなどアプリケーションを呼び出す側と「セカンダリポート（被駆動側）」：データベースや外部サービスなどアプリケーションが呼び出す側という2種類のポートを区別する点が特徴でしょう。
3つのアーキテクチャの共通点と相違点
オニオン・クリーン・ヘキサゴナルの3つのアーキテクチャはすべて「ドメインを中心に置き、外部技術からの独立性を確保する」という同じ思想から生まれたものです。
これらはまとめて「同心円系アーキテクチャ」や「ポートアダプターアーキテクチャ」の仲間として理解することができます。
実際のプロジェクトで採用する際は、どれかが絶対的に優れているということはなく、チームの知識・プロジェクトの性質・DDDの採用有無などを考慮して選択することが重要でしょう。
レイヤードアーキテクチャとの違い
レイヤードアーキテクチャ（階層型アーキテクチャ）は最も古くから使われてきた設計パターンで、プレゼンテーション層→ビジネス層→データアクセス層という上から下への依存関係を持ちます。
オニオンアーキテクチャなどとの最大の違いは、ビジネス層がデータアクセス層に直接依存する点です。
この依存関係により、データベースの変更がビジネスロジックにまで影響し、テストの際にデータベースへの接続が必要になるというデメリットがあります。
オニオンアーキテクチャはこのレイヤードアーキテクチャの課題を解決するために依存関係を逆転させたアーキテクチャとして捉えることができるでしょう。
設計パターンの選択基準と使い分け
続いては、設計パターンの選択基準と使い分けを確認していきます。
どのアーキテクチャパターンを選択すべきかは、プロジェクトの特性と目的によって判断する必要があります。
オニオンアーキテクチャが適したプロジェクト
オニオンアーキテクチャが特に適しているのは、ドメイン駆動設計（DDD）を積極的に採用する複雑な業務アプリケーションです。
複雑なビジネスルールが多く存在する・業務の概念をコードに忠実に反映したい・ドメインエキスパートとの協働を重視するというプロジェクトでは、DDDと組み合わせたオニオンアーキテクチャが威力を発揮するでしょう。
各アーキテクチャの使い分け目安：
・複雑な業務システム＋DDD採用 → オニオンアーキテクチャ
・汎用的・大規模システム・DDD非依存 → クリーンアーキテクチャ
・外部システムとの接続が多いシステム → ヘキサゴナルアーキテクチャ
・小〜中規模のシンプルなCRUD → レイヤードアーキテクチャ
クリーンアーキテクチャが適したプロジェクト
クリーンアーキテクチャはDDDに限定しない汎用性の高さから、複数のフレームワークや技術スタックを使う大規模なシステムや、長期にわたって保守・進化させるシステムに適しています。
Webバックエンドだけでなく、デスクトップアプリケーション・モバイルアプリ・マイクロサービスなど幅広い種類のシステムにクリーンアーキテクチャを適用できるでしょう。
実際のプロジェクトでの折衷アプローチ
実際のプロジェクトでは、どれか一つのアーキテクチャパターンを純粋に採用するのではなく、複数のパターンのエッセンスを組み合わせた折衷アプローチをとることが多いでしょう。
たとえば「基本構造はクリーンアーキテクチャのレイヤー定義を採用しつつ、ドメイン層の設計はオニオンアーキテクチャとDDDの概念を取り入れる」という組み合わせが実践的なアプローチの一つです。
アーキテクチャパターンは手段であり目的ではないため、各パターンの背景にある原則と目指す品質特性を理解した上で、プロジェクトに最適な設計を選択することが最も重要でしょう。
まとめ
本記事では、オニオンアーキテクチャとクリーンアーキテクチャの違い・共通点・ヘキサゴナルアーキテクチャとの比較・使い分けについて詳しく解説しました。
両者は同じ根本的な設計思想を持ち、ドメインを中心に外側への依存禁止という共通原則のもとで異なる表現・用語・レイヤー粒度を持つ設計パターンです。
DDD採用の複雑な業務システムにはオニオンアーキテクチャが、汎用性を重視する大規模システムにはクリーンアーキテクチャが適しており、プロジェクトの特性に応じた選択と折衷アプローチが実践的でしょう。
各パターンの背景にある原則を理解した上で柔軟に応用することが、高品質なソフトウェアアーキテクチャの実現につながります。
