はじめに
クリーンアーキテクチャの概要を説明します。
記事の構成
- Clean Architecture超概要編(前半)
章構成: 要約 = 手段 + 効果 - Clean Architecture概要編(中半)
章構成: 手段の説明
今ここ👆 - Clean Architectureソース解説編(後半)
手段
- 各レイヤー層に分ける
- 依存の方向性の決定: 依存性逆転の原則
1. 各レイヤー層に分ける
各レイヤーは、アプリケーションの異なる側面を管理し、その責務を明確にします。
これにより、関心の分離が実現され、システムの柔軟性とメンテナンス性が向上します。
この表では、クリーンアーキテクチャにおける各レイヤーの役割とそれに対応する具体的なコンポーネントを明確にしています。
| No | レイヤー名 (英語) | 説明 (日本語) |
|---|---|---|
| 1 | Entity | アプリケーションの基本的なデータモデルやビジネスルールを定義するレイヤー。 |
| 2 | Use Case | ユーザーの行動やビジネスプロセスを具体化するユースケースを実装するレイヤー。 |
| 3 | Controller | ユーザーのリクエストを受け取り、ビジネスロジックを呼び出し、結果を処理する層。 |
| 3 | Presenter | データを加工してUIに適した形式で表示するためのロジックを担当する層。 |
| 3 | Gateway | データベースや外部サービスへのアクセスを管理する層。 |
| 4 | Device | ハードウェアやデバイス間のインタラクションを処理する層。 |
| 4 | Web | WebベースのインターフェイスやAPIを通じた外部通信を管理する層。 |
| 4 | DB | データベースとのやり取りを担当する層。 |
| 4 | UI | ユーザーインターフェースとのやり取りを担当する層。 |
| 4 | External Interfaces | 外部システムやAPIとの連携を管理する層。 |
| https://www.ogis-ri.co.jp/otc/hiroba/others/OOcolumn/single-responsibility-principle.html
2. 依存の方向性の決定: 依存性逆転の原則
クリーンアーキテクチャの「依存性逆転」とは
システム設計における依存関係の方向を変える概念です。通常、高レベルのビジネスロジック(Entity層)は低レベル(UI層)の実装詳細（例えばデータベースやUI）に依存しますが、クリーンアーキテクチャではこの依存関係を逆転させます。つまり、低レベルの実装が高レベルのポリシーに依存するように設計されます。これにより、ビジネスロジックが外部の変更に強くなります。
依存性逆転の目的
- 逆転の意味: 通常、高レベルのビジネスロジックは低レベルの実装詳細に依存しますが、依存性逆転ではこの関係が逆になります。
- 実装の独立性: 低レベルの実装（データベースやUIなど）が高レベルのビジネスルールやポリシーに依存するように設計されます。
図解すると以下のようになります。
- インターフェースの利用: 依存性逆転は、インターフェースや抽象クラスを用いることで実現されます。
- 柔軟性の向上: この逆転により、ビジネスロジックが具体的な実装詳細から独立し、変更に対して柔軟に対応できるようになります。
実装
// インターフェース定義
public interface IData
// インターフェース定義
public interface IDataRepository {
void SaveData(string data);
}
// 低レベルの実装クラス
public class SqlDataRepository : IDataRepository {
public void SaveData(string data) {
// SQLデータベースにデータを保存するロジック
}
}
// 高レベルビジネスロジッククラス
public class BusinessLogic {
private readonly IDataRepository _dataRepository;
public BusinessLogic(IDataRepository dataRepository) {
_dataRepository = dataRepository;
}
public void ProcessData(string data) {
// ビジネスロジックの処理
_dataRepository.SaveData(data);
}
}