# Clean Architecture
抽象度に応じてレイヤーを分けて、より具体的なレイヤーからより抽象的なレイヤーに対する依存のみにしましょう。これによって最も抽象的なビジネスルールが、UI、データベース、フレームワークなどの変更に影響を受けなくなります。つまり、UI、データベース、フレームワークなどを気軽に変更できるようになります。
このルールをアーキテクチャとして命名したものが Clean Architecture です。次の4つのレイヤーに分けるパターンが有名です。
- Enterprise Business Rules
- ドメイン固有のルールを扱う
- 最も抽象的な層
- Application Business Rules
- アプリ固有のルールを扱う
- Entitiesを組み合わせて問題を解決する層
- 以下のインターフェースを持つ
- ゲートウェイ
- Web API との入出力を扱う
- リポジトリ
- DBとの入出力を扱う
- ゲートウェイ
- Interface Adapters
- 外部とのやりとりを扱う
- 内部のデータを外部用に変換したり、その逆を行う層
- 要素の例
- コントローラ
- 外部からの入力をハンドリングする
- プレゼンター
- 外部への出力を整形する
- ゲートウェイ、リポジトリの実装クラス
- コントローラ
- Frameworks & Drivers
- 外部での処理を扱う
- 最も具体的な層
- 外部の例
- フレームワーク
- DBドライバ
- Web API
- ファイルシステム
- UI
前述したとおり、重要なのは依存を単方向にすることです。レイヤーの数は規模に応じて増減します。
NOTE
具体的な層から抽象的な層に対してのみ依存する
# 関連
# 安定依存の原則 / 安定度・抽象度等価の原則
Clean Architecture は安定依存の原則と安定度・抽象度等価の原則をアーキテクチャにしたものです。
# 依存関係逆転の原則
Clean Architecture を実現するには依存関係を逆転させる必要があります。