はじめに
Robert C. Martin（Uncle Bob）が提唱した Clean Architecture は、
ソフトウェアを「ビジネスルール」と「技術的詳細」に明確に分離するアーキテクチャです。
その特徴的な図が 同心円モデル（Concentric Circles） です。
このモデルは「依存関係の流れ」と「保護すべきものの優先度」を直感的に示しています。
1. 同心円モデルの構造
CleanArchitecture from https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
2. 各層の役割
Entities（エンティティ）
- エンタープライズビジネスルール
- 最も普遍的で長命なルール
- 外部要素に依存しない
例：Account.withdraw() のようなビジネスロジック
Use Cases（ユースケース）
- アプリケーション固有のビジネスルール
- システムのユースケースを実現する手続き
- エンティティを組み合わせて具体的な処理を表現
例：WithdrawMoney ユースケース
Interface Adapters（インターフェースアダプタ）
- 外部世界と内側をつなぐ変換層
- DTO, Controller, Presenter, Repository 実装など
- データ形式を内側のモデルに変換
例：UserResponse.toDomain()
Frameworks & Drivers（フレームワークとドライバ）
- 最も外側にある技術的詳細
- Web, DB, UI, 外部サービス、フレームワークなど
- ここが変わっても内側に影響を与えない
例：Spring, Flutter, MySQL, Firebase
3. 依存関係のルール
Clean Architecture では、依存の方向 が最も重要です。
- 外側 → 内側 にしか依存してはいけない
- 内側のルール（Entities, Use Cases）は外側を知らない
- 内側は永続化・UI・フレームワークから独立している
4. Clean Architecture のメリット
-
変更に強い
- DBを変えてもビジネスルールは影響を受けない
-
テスト容易性
- UseCaseやEntityはモック化可能
-
ビジネス中心の設計
- 構造が「システムの意図」を叫ぶ（Screaming Architecture）
まとめ
Clean Architecture（同心円モデル）は：
- 内側（Entities, Use Cases） → 不変・ビジネス中心
- 外側（Frameworks, UI, DB） → 可変・技術依存
- 依存関係は必ず 外から内へ
良いアーキテクチャとは、変わるもの（技術詳細）から、変わらないもの（ビジネスルール）を守る構造 を持つことです。