TL;DR
Robert C. Martin（Uncle Bob）が 2012 年に提唱したアーキテクチャ。ソフトウェアを同心円状のレイヤに分け、ソースコードの依存は内側にだけ向けるという「依存性のルール（The Dependency Rule）」で、ビジネスルールを外部の要素から切り離す。
なぜ必要か
ヘキサゴナルアーキテクチャ、オニオンアーキテクチャ、叫ぶアーキテクチャ、DCI、BCE といったアーキテクチャは、どれもソフトウェアをレイヤに分けて関心を分離することを目指している。クリーンアーキテクチャはこれらを 1 つの考え方にまとめたものである。
こうして作ったシステムは、フレームワーク、UI、データベース、その他の外部の要素から独立し、それらがなくてもビジネスルールをテストできる。
仕組み
円は内側から次の 4 つに分かれる。
- Entities: 企業全体のビジネスルール。外部が変わっても最も変わりにくい
- Use Cases: アプリケーション固有のビジネスルール。エンティティとの間のデータの流れを調整する
- Interface Adapters: ユースケースやエンティティに都合のよい形と、外部に都合のよい形の間でデータを変換する。MVC のプレゼンター、ビュー、コントローラがここに入る
- Frameworks and Drivers: データベースや Web フレームワークなど。主につなぎのコードを書く
内側の円のコードは外側の円で宣言された名前に触れてはいけない。制御の流れが依存と逆向きになる場所では、依存性逆転の原則を使う。たとえば、ユースケースは内側で定義したインタフェースを呼び出し、外側のプレゼンターがそれを実装する。
境界を越えて渡すのは、単純な構造体や DTO、関数の引数のような、独立した単純なデータ構造である。エンティティやデータベースの行をそのまま渡してはいけない。データは常に内側の円に都合のよい形で渡す。
注意点
円が 4 つである必要はなく、図は模式的なものである。ただし、レイヤがいくつであっても依存性のルールは常に適用される。
関連
- ヘキサゴナルアーキテクチャ
- オニオンアーキテクチャ
- レイヤードアーキテクチャ
- 叫ぶアーキテクチャ
- 依存性逆転の原則
- Clean Architecture 達人に学ぶソフトウェアの構造と設計