共通する目的
「システムの変更に強く、テストがしやすいコードを書くこと」
1. 共通のキーワード：依存性の逆転
これらのアーキテクチャを理解する上で最も重要なルールは、**「内側（ビジネスロジック）は、外側（データベースや画面）のことを知ってはいけない」**という点。
これを**「依存の方向を内側に向ける」**と言う。
2. クリーンアーキテクチャ (Clean Architecture)
ボブおじさん（Robert C. Martin）が提唱した、現在最も有名な設計思想の一つ。
Shutterstock
4つの層
- Entities（エンティティ）： 最中心部。ビジネスの根本的なルール。特定のアプリに依存しない（例：ECサイトなら「商品」「注文」の概念）。
- Use Cases（ユースケース）： 「注文をキャンセルする」といった、アプリ固有のビジネスロジック。
- Interface Adapters（コントローラー/プレゼンター）： 外側のデータを内側で使いやすい形に、あるいはその逆に変換する変換器。
- Frameworks & Drivers（Web/DB/外部サービス）： 一番外側。DBやWebフレームワークなど、具体的で「変更されやすい」もの。
ポイント： データベースをPostgreSQLからMongoDBに変えたとしても、中心の「Entities」や「Use Cases」は1文字も書き直さなくて済むのが理想。
3. オニオンアーキテクチャ (Onion Architecture)
ジェフリー・パレルモが提唱したもので、クリーンアーキテクチャと非常によく似ている。
特徴
- ドメイン中心： データの保存方法ではなく、「何をするプログラムか」というドメイン（業務知識）を中心。
- タマネギの皮： 外側の層は、自分より内側の層にだけ依存する。
- 依存性の注入 (DI)： インターフェース（抽象）を内側に置き、実装（具体）を外側に置くことで、内側が外側に依存しないように制御する。
4. ヘキサゴナルアーキテクチャ (Ports and Adapters)
これらすべての元祖に近い考え方がこれ。
Shutterstock
特徴
- ポート（港）とアダプター： 中心にあるアプリケーションを「六角形（ヘキサゴン）」に見立て、外の世界（DB、UI、テスト、他社API）を接続先として扱う。
- 差し替え自由： 本物のDBをつなぐ「アダプター」も、テスト用のダミーをつなぐ「アダプター」も、同じ「ポート」に差し込むだけ、という考え方。
5. メリットとデメリット
メリット
| テストが楽 | DBや画面がなくても、ロジックだけでユニットテストができる。 |
| フレームワークに依存しない | ReactやRailsのバージョンアップ、フレームワーク自体の乗り換えに強くなる。 |
| ビジネスルールが明確 | コードを読めば「何ができるシステムか」がすぐ分かり、仕様変更に対応しやすい。 |
デメリット
- コード量が増える： データを変換するだけのクラスやインターフェースをたくさん作る必要がある。
- 難易度が高い： チーム全員がこの思想を理解していないと、依存関係がぐちゃぐちゃになり逆効果。
6. 結論：どれを使うべき？
現代のWeb開発では、これらを厳格に守るというよりは、**「エッセンスを取り入れる」**のが主流。
- ビジネスロジックと、DBアクセスやUI表示を分離する。
- インターフェースを使って、具体的なライブラリに依存しすぎないようにする。
まずはこの2点から意識するのが、保守性の高いコードへの近道である。