クリーンアーキテクチャ

定義

クリーンアーキテクチャとは、ヘキサゴナルアーキテクチャやオニオンアーキテクチャなどのアーキテクチャを単一の概念に無理なく統合する試み。

これらのアーキテクチャの共通点は以下の通り。

• 目的が「関心事の分離」
• ソフトウェアをレイヤーに分割することで目的を達成
• 少なくとも、ビジネスルールのレイヤーと、ユーザやシステムとのインターフェイスとなるレイヤーを持つ

---

The Clean Architectureより引用

同心円の図

Enterprise Business Rules

エンティティを含むレイヤー

Entities

企業全体の最重要ビジネスルール

Application Business Rules

ユースケースを含むレイヤー

Use Cases

アプリケーション固有のビジネスルール

Interface Adapters

• 内側のレイヤーに便利なフォーマットから、外側のレイヤーに便利なフォーマットにデータを変換
• 外側のレイヤーに便利なフォーマットから、内側のレイヤーに便利なフォーマットにデータを変換

Controllers

以下処理を行う。

1. Web サーバなどからデータを受け取る
2. ユースケース用の入力データに変換
3. 入力データをユースケースへ渡す

Presenters

以下処理を行う。

1. ユースケースからデータを受け取る
2. ビュー用の入力データに変換して返す

Gateways

外側のレイヤーからのデータを抽象化

Frameworks & Drivers

フレームワークやツールを含むレイヤー

右下の簡易的なクラス図

DIP（依存性逆転の原則）を使って、どのように依存方向を逆転させるのか言及している。

存在意義

以下特性を持つシステムを実現する。

• フレームワーク非依存
• ビジネスルールが
  • テスト可能
  • UI 非依存
  • データベース非依存

活用方法

DB を使った Web ベースの Java システム

Clean Architecture 達人に学ぶソフトウェアの構造と設計より引用

こういった本格的な境界を構築するコストの高さは、クリーンアーキテクチャ提唱者も認めている。
以下を用意、保守するのは簡単なことではない。

• InputBoundary と OutputBoundary
• InputData と OutputData
• 各境界のコンパイルやデプロイを独立させるための依存性管理

これらを一部諦める選択肢を用意してくれている。
あくまで例だが、以下の手段が明示されている。

• 複数境界を 1 つのコンポーネントにまとめる
  • コード上は本格的な境界を設定するが各境界の完全な独立を諦める
• Strategy パターン
  • Boundary を一つにする
• Facade パターン
  • 依存関係の逆転も断念する

オーバーエンジニアリングのリスクは大きい。
どのような選択をするにせよ、メリットとデメリットを比較して決断しなければならない。

小さい規模のシステムだったら、構成は以下で十分。

• UI
• ビジネスルール
• データベース