クリーンアーキテクチャとは
クリーンアーキテクチャは、ソフトウェア設計の原則とパターンを用いて、柔軟で保守性の高いシステムを構築するためのアプローチです。
主にRobert C. Martin（通称「Uncle Bob」）によって提唱されました。
このアーキテクチャの目的は、コードの可読性、再利用性、テストの容易さを向上させることです。
基本概念
クリーンアーキテクチャは、以下のような層（レイヤー）で構成されます。
※各々の解釈によって、命名など細かいところには違いがありますが、層の概念はいずれも同じです。
1. エンティティ（Entities）
- ビジネスルールやドメインオブジェクトを含む層
- システム全体の中心に位置し、他の層に依存しない
2. ユースケース（Use Cases）
- アプリケーション固有のビジネスロジックを含む層
- エンティティを利用して特定の操作や処理を行う
3. インターフェース（Interface Adapters）
- データの変換や、外部システムとのやりとりを行う層
- ユースケースやエンティティが理解できる形式にデータを変換するためのアダプタ
4. フレームワークとドライバ（Frameworks and Drivers）
- データベース、Webフレームワーク、UIなどの外部システムやツールを含む層
- アプリケーションの最も外側に位置し、他の層に依存する
依存関係のルール
クリーンアーキテクチャでは、依存関係は「内側」に向かってのみ持つことが許されています。
具体的には、外側の層が内側の層に依存することはあっても、内側の層が外側の層に依存してはいけません。
これは、「依存性逆転の原則（Dependency Inversion Principle） 」に基づいています。
依存性逆転の原則
依存性逆転の原則（Dependency Inversion Principle, DIP）は、ソフトウェア設計におけるSOLID原則の一つで、柔軟で保守性の高いコードを書くための重要なガイドラインです。
この原則は、オブジェクト指向プログラミングの依存関係の管理に焦点を当てており、特にモジュール間の依存関係を逆転させることで、システムをより柔軟にすることを目的としています。
依存性逆転の原則の定義
依存性逆転の原則は、次の2つのルールで定義されます。
- 高レベルモジュールは低レベルモジュールに依存してはならない。両者は抽象に依存すべきである。
- 抽象は詳細に依存してはならない。詳細は抽象に依存すべきである。
具体例
悪い例（DIPに違反している例）
class Light {
public void turnOn() {
System.out.println("Light is on");
}
}
class Switch {
private Light light;
public Switch(Light light) {
this.light = light;
}
public void operate() {
light.turnOn();
}
}
この例では、 Switch クラス（高レベルモジュール）は Light クラス（低レベルモジュール）に直接依存しています。
この設計では、 Light クラスに変更があった場合、 Switch クラスも変更する必要があります。
良い例（DIPに従っている例）
interface Switchable {
void turnOn();
}
class Light implements Switchable {
public void turnOn() {
System.out.println("Light is on");
}
}
class Switch {
private Switchable device;
public Switch(Switchable device) {
this.device = device;
}
public void operate() {
device.turnOn();
}
}
この例では、 Switch クラスは Switchable というインターフェース（抽象）に依存しています。
具体的なLight クラスは、そのインターフェースを実装しています。
このように設計することで、 Switch クラスは Light クラスの具体的な実装に依存しなくなり、他の Switchable デバイス（例えば、Fan クラスなど）を簡単に追加できます。
メリット
保守性の向上
コードの変更が一部に限定され、他の部分への影響を最小限に抑えることができます。
新しい機能の追加や既存の機能の変更が容易です。
テストの容易さ
各層が独立しているため、ユニットテストが容易になります。
モックやスタブを使って外部依存を排除し、ビジネスロジックのテストに集中できます。
柔軟性と拡張性
新しいフレームワークやデータベースへの移行が容易です。
既存のビジネスロジックを変更せずに、UIやインフラストラクチャを変更できます。
再利用性
ビジネスロジックやユースケースが他のプロジェクトやコンテキストで再利用可能です。
再利用可能なコンポーネントを構築しやすくなります。
まとめ
クリーンアーキテクチャは、ソフトウェアを柔軟で保守性の高いものにするための設計手法です。
各層が明確に分離され、依存関係が内側に向かうように設計されているため、コードの変更やテストが容易になります。
結果として、プロジェクトの長期的な成功と効率的な開発が可能になります。