クリーンアーキテクチャ のすすめ 2022/05/22

坂口　大河　Sakaguchi Taiga 高校教員　→ Web系エンジニア（3年目） バックエンドエンジニア 自己紹介 Go, Java, Vue.js, Nuxt.js, GCP, AWS @taiga_skg taigaskg

クリーンアーキテクチャ

クリーンアーキテクチャ...? ヘキサゴナルアーキテクチャ オニオンアーキテクチャ レイヤードアーキテクチャ MVVM

最重要ルール レイヤーに分割し、関心事が分離されていること。 ソースコードの依存性は、内側だけに向かっていること。 （依存性のルール） 1 2

関心事の分離とは ビジネスロジック UI DB 外部API フレームワーク ユースケース etc... Entities ビジネスルールをカプセル化。メソッドやデータ構造をもつ。 関心事 レイヤー Usecases アプリケーション固有のビジネスルール。システムの全てのユースケ ースが実装されている。Entityの入出力を制御し、ユースケースの目 標を達成。 Interface Adapters 外部サービス・DB ↔︎ UsecaseやEntity（内部）間で便利な形式にデ ータ変換。 Frameworks & Drivers DBやWeb FWなどFWやツールで構成。コードはあまり書かない。書く としても、ひとつ内側のレイヤーとやり取りするための変換コード。 SQL Controller

関心事の分離とは ビジネスロジック UI DB 外部API フレームワーク ユースケース etc... Entities ビジネスルールをカプセル化。メソッドやデータ構造をもつ。 関心事 レイヤー Usecases アプリケーション固有のビジネスルール。システムの全てのユースケ ースが実装されている。Entityの入出力を制御し、ユースケースの目 標を達成。 Interface Adapters 外部サービス・DB ↔︎ UsecaseやEntity（内部）間で便利な形式にデ ータ変換。 Frameworks & Drivers DBやWeb FWなどFWやツールで構成。コードはあまり書かない。書く としても、ひとつ内側のレイヤーとやり取りするための変換コード。 SQL Controller

関心事の分離とは ビジネスロジック UI DB 外部API フレームワーク ユースケース etc... Entities ビジネスルールをカプセル化。メソッドやデータ構造をもつ。 関心事 レイヤー Usecases アプリケーション固有のビジネスルール。システムの全てのユースケ ースが実装されている。Entityの入出力を制御し、ユースケースの目 標を達成。 Interface Adapters 外部サービス・DB ↔︎ UsecaseやEntity（内部）間で便利な形式にデ ータ変換。 Frameworks & Drivers DBやWeb FWなどFWやツールで構成。コードはあまり書かない。書く としても、ひとつ内側のレイヤーとやり取りするための変換コード。 SQL Controller

関心事の分離とは ビジネスロジック UI DB 外部API フレームワーク ユースケース etc... Entities ビジネスルールをカプセル化。メソッドやデータ構造をもつ。 関心事 レイヤー Usecases アプリケーション固有のビジネスルール。システムの全てのユースケ ースが実装されている。Entityの入出力を制御し、ユースケースの目 標を達成。 Interface Adapters 外部サービス・DB ↔︎ UsecaseやEntity（内部）間で便利な形式にデ ータ変換。 Frameworks & Drivers DBやWeb FWなどFWやツールで構成。コードはあまり書かない。書く としても、ひとつ内側のレイヤーとやり取りするための変換コード。 SQL Controller

関心事の分離とは ビジネスロジック UI DB 外部API フレームワーク ユースケース etc... Entities ビジネスルールをカプセル化。メソッドやデータ構造をもつ。 関心事 レイヤー Usecases アプリケーション固有のビジネスルール。システムの全てのユースケ ースが実装されている。Entityの入出力を制御し、ユースケースの目 標を達成。 Interface Adapters 外部サービス・DB ↔︎ UsecaseやEntity（内部）間で便利な形式にデ ータ変換。 Frameworks & Drivers DBやWeb FWなどFWやツールで構成。コードはあまり書かない。書く としても、ひとつ内側のレイヤーとやり取りするための変換コード。 SQL Controller

依存性とは 依存しているとは、別のモジュールで定義された変数、関数、エンティティなどを使っていること Module A Module B Call

依存性のルール ソースコードの依存性は、内側だけに向かっていること。 内側の円は、外側の円について何も知ることはない。 外側から内側のものを呼び出す事は可能。 → 変数、関数、クラス、エンティティ、フォーマットなど 外側から内側に影響を与えるべきでない。 ※ 4つの円はあくまで概要。必ずしも4つの円である必要なない。

境界を越えるには？ ユーザー登録のユースケースを考える。 Entities層(最内側)

Usecases層(内側) Interface Adapters層（外側）

依存性逆転の原則（DIP） 上位レベルの方針の実装コードは、下位レベルの詳細の実装コー ドに依存すべきでなく、逆に詳細が方針に依存すべきであるとい う原則

依存性逆転の原則（DIP） 上位レベルの方針の実装コードは、下位レベルの詳細の実装コー ドに依存すべきでなく、逆に詳細が方針に依存すべきであるとい う原則 ⇒ 具象ではなく、抽象に依存すべき

インターフェース とは

依存性逆転の原則（DIP） 具象ではなく、抽象に依存すべき ⇒ インターフェースに依存すべき。 Call Class A (Struct) Class B（Struct） Interface Implement Call Boundary 内側

Entities層(最内側)

Usecases層(内側) Interface Adapters層（外側）

フレームワーク非依存 テスト可能 UI非依存 データベース非依存 外部エージェント非依存 何が嬉しいのか システムをFWの制約で縛る のではなく、ツールとして 利用できる。 UI、DB、Web Server、 etc...がなくてもビジネスル ールのテストができる。 システムの他の部分を変更 することなくUIを変更でき る。 ビジネスルールはDBに束縛 されず、置き換え可能。 ビジネスルールは、外側の インターフェースについて 何も知らない。

ご清聴ありがとうございました！