クリーンアーキテクチャ

https://gyazo.com/cb467d60efb208b529e01b01ab53bf9c

メモ

本質

依存関係を一方向に整理する

依存の向きは内側にのみ向かう。

概要

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

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

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

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

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

依存関係が一方向

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

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

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

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

こうではなく

SQLHandler←EvilRepository

こうする

SQLHandler→SQLHandler Interface←EvilRepository

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

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

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

原則

依存関係逆転の法則

関心の分離

依存性のルール

メリット

変更容易性

美しい

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

テスタビリティを高める

UIの独立性

デメリット

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

コード量が多くなる

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

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

/icons/hr.icon

レイヤー分類

Entities

システムの本質的なルール・概念を表現する層

特徴

✅ 何にも依存しない

✅ フレームワーク非依存

✅ データベース非依存

✅ UI非依存

Use Cases

Interactor

ドメインを操作してユースケース（業務動作）を実現する

外部I/Oを抽象的に扱い、業務ロジックを定義

「ドメインを使って何をするか」を定義し、「どうやってやるか（DBやAPI）」は知らない

特徴

✅ Domain層のみに依存

✅ インターフェース（ポート）を通じてデータアクセス

✅ 具体的な実装を知らない

Controllers

Presenters

Gateways

外部世界（Web, DB, UI）と内側のドメイン/ユースケースの橋渡しをする層

特徴

✅ UseCase層とDomain層に依存

✅ 外部形式（JSON、HTTP）とDTO/ドメインモデルを変換

✅ プレゼンテーション層（Controller）を含む

Web

UI

External Interfaces

Devices

DB

実際のフレームワークや外部ツールを動かす「起動・構成」部分

アプリ全体を組み立てる（DIする）

特徴

✅ Domain層のインターフェースを実装

✅ データベース、ファイルシステム、外部APIなど

✅ フレームワーク特有のコード

/icons/hr.icon

参照