クリーンアーキテクチャ

https://gyazo.com/cb467d60efb208b529e01b01ab53bf9c

メモ

本質

依存性は内側だけに向かっていなければいけない

概要

DBやフレームワークからの独立性を確保するためのアーキテクチャ

使用するフレームワークに関わらず通用する普遍的な設計手法

図は概要なので4層以上にもなる

Use Casesから内側はフレームワークの機能を使わないで実装するべし

ビジネス的価値を生み出しているドメイン層を他の何にも依存させない

依存関係が一方向

内側の層が外側について何も知ることはできない

CAは特定の技術や言語に依存しない

が依存性や可視性をコントロールできるような言語とかと相性が良い

境界をまたぐ時に依存性の向きを逆転させるためにインターフェースを噛ませる

こうではなく

SQLHandler←EvilRepository

こうする

SQLHandler→SQLHandler Interface←EvilRepository

クリーンアーキテクチャが解決すること

ソフトウェアの成長に伴って変更容易性を維持し続ける

変更容易性を維持するためにはドメイン層は他のフレームワークや層に依存してはならない

原則

依存関係逆転の法則

関心の分離

依存性のルール

メリット

変更容易性

美しい

DB/フレームワークなどの外部パーツの置き換えを最小限の手間で行える

テスタビリティを高める

UIの独立性

デメリット

パッケージ構成が広がり構築が難しい

コード量が多くなる

クラス数の増大とデータ構造の載せ替えによるパフォーマンス劣化

サブプロジェクトを使うことによってdomain層がusecaseやrepositoryに依存できないようにできる

/icons/hr.icon

レイヤー分類

Entities

Use Cases

Interactor

Controllers

Presenters

Gateways

Web

UI

External Interfaces

Devices

DB

/icons/hr.icon

参照