アーキテクチクリーンアーキテクチャ設計原則
レイヤードアーキテクチャ
- ソフトウェアを関心ごとに分けた構造の一つで、一般的には3つのレイヤーで構成
- プレゼンテーション層、ビジネスロジック層、データアクセス層
- 何層までという決まりはなく、関心ごとにレイヤーを分け、依存のルールを守ことが重要
プレゼンテーション層
- エンドユーザーと直接対話する部分を担当
- 例えば、GUI、CLI
- 外部からのリクエスをと受け取り、その結果をユーザーに返す役割
ビジネスロジック層
- 企業のビジネスルールをカプセル化している部分
- 外部の変更による影響を受けにくい部分であり、ソフトウェアのコアな機能を提供
- 例えば、銀行アプリケーションでの口座間の資金移動のロジックはこの層に含まれる
データアクセス層
- データの永続化を提供するレイヤー
- データベースやファイルシステム、あるいは外部サービスにデータを保存・取得する機能を提供
- ビジネスロジック層が具体的にデータ保存方法に依存しないようにするためのカプセル化を実行
レイヤードアーキテクチャの課題
- ビジネスロジック層がデータアクセス層に依存し、その逆が許されない
- 本来ビジネスルールの中心であるはずのドメイン（ビジネスロジック）が、永続化技術の都合に縛られる
- テスタビリティの低下
- ビジネスロジックを単体でテストしたいのに、下位層（DB、外部API）を起動しないと動かない構造になりがち
- モック差し替えのフックがないと、E2Eに近いテストばかりになる
ヘキサゴナルアーキテクチャ
- レイヤードアーキテクチャの課題を解決するために提案
- レイヤードアーキテクチャの欠点を解消し、ビジネスロジックを中心として依存関係を構築する構造になっている
- ビジネスロジックを中心に置き、その周辺に「ポート」と「アダプタ」を配置
- ビジネスロジックが外部システムに直接依存しない構造を作る
ポートとアダプタ
- ポート：ビジネスロジックが外部システムと通信するためのインターフェース
- 処理をビジネスロジックから切り離し、どのように外部とやり取りをするかを定義
- ビジネスロジックがどのような技術に依存するか関係がなくなる
- アダプタ：ポートで定義されたインターフェースを実装する具体的なコンポーネント
- 例えば、データベースとのやり取りや、ユーザーインターフェースとの連携を行う部分
- アダプタを変更することで、異なるデータベースやUIに対応することが容易
依存性注入（Dependency Injection：DI）
- ビジネスロジックがどのアダプタを使用するかを外部から注入すること
- ビジネスロジックは外部の詳細を知らずに、ポートを通じて必要な機能を呼び出すことができる
- テスト時にデータベースを使わずにモックオブジェクトを使用してテストを行うことができる
クリーンアーキテクチャ
- ヘキサゴナルアーキテクチャやオニオンアーキテクチャなど、様々なアーキテクチャのアイデアを統合し、一般化したもの
- 関心ごとを分離し、依存関係をビジネスロジックに向けること
- クリーンアーキテクチャの特徴
- フレームワークに依存しない：ビジネスロジックはフレームワークに依存しないため、フレームワークの変更が可能
- テスト可能：外部システムに依存しないため、ビジネスロジックのテストが容易
- UIに依存しない：UIの変更がビジネスロジックに影響を与えない
- データベースに依存しない：データベースの種類や構造が変更されても、ビジネスロジックには影響しない
- 外部エージェントに依存しない：外部サービスやライブラリの変更がビジネスロジックに影響を与えない