Open3
クリーンアーキテクチャ
からす定義
クリーンアーキテクチャとは、ヘキサゴナルアーキテクチャやオニオンアーキテクチャなどのアーキテクチャを単一の概念に無理なく統合する試み。
これらのアーキテクチャの共通点は以下の通り。
- 目的が「関心事の分離」
- ソフトウェアをレイヤーに分割することで目的を達成
- 少なくとも、ビジネスルールのレイヤーと、ユーザやシステムとのインターフェイスとなるレイヤーを持つ
同心円の図
Enterprise Business Rules
エンティティを含むレイヤー
Entities
企業全体の最重要ビジネスルール
Application Business Rules
ユースケースを含むレイヤー
Use Cases
アプリケーション固有のビジネスルール
Interface Adapters
- 内側のレイヤーに便利なフォーマットから、外側のレイヤーに便利なフォーマットにデータを変換
- 外側のレイヤーに便利なフォーマットから、内側のレイヤーに便利なフォーマットにデータを変換
Controllers
以下処理を行う。
- Web サーバなどからデータを受け取る
- ユースケース用の入力データに変換
- 入力データをユースケースへ渡す
Presenters
以下処理を行う。
- ユースケースからデータを受け取る
- ビュー用の入力データに変換して返す
Gateways
外側のレイヤーからのデータを抽象化
Frameworks & Drivers
フレームワークやツールを含むレイヤー
右下の簡易的なクラス図
DIP（依存性逆転の原則）を使って、どのように依存方向を逆転させるのか言及している。
からす存在意義
以下特性を持つシステムを実現する。
- フレームワーク非依存
- ビジネスルールが
- テスト可能
- UI 非依存
- データベース非依存
からす活用方法
DB を使った Web ベースの Java システム
Clean Architecture 達人に学ぶソフトウェアの構造と設計より引用
こういった本格的な境界を構築するコストの高さは、クリーンアーキテクチャ提唱者も認めている。
以下を用意、保守するのは簡単なことではない。
- InputBoundary と OutputBoundary
- InputData と OutputData
- 各境界のコンパイルやデプロイを独立させるための依存性管理
これらを一部諦める選択肢を用意してくれている。
あくまで例だが、以下の手段が明示されている。
- 複数境界を 1 つのコンポーネントにまとめる
- コード上は本格的な境界を設定するが各境界の完全な独立を諦める
- Strategy パターン
- Boundary を一つにする
- Facade パターン
- 依存関係の逆転も断念する
オーバーエンジニアリングのリスクは大きい。
どのような選択をするにせよ、メリットとデメリットを比較して決断しなければならない。
小さい規模のシステムだったら、構成は以下で十分。
- UI
- ビジネスルール
- データベース