Robert C. Martinによる「Clean Architecture 達人に学ぶソフトウェアの構造と設計」を読んだまとめ。
クリーンアーキテクチャは例の同心円の図で説明され一見複雑に見えるが、シンプルなルールからなる。
優れたアーキテクチャとは？
これまでの優れたシステムのアーキテクチャでは、以下のような特性を持つ。
フレームワークに依存しない
アーキテクチャは、ソフトウェアのライブラリに依存しない。テスト可能
ビジネスルールは、UI、データベース、ウェブサーバーなどの外部要素がなくてもテスト可能である。UI 非依存
UI は、システムの他の部分を変更することなく、簡単に変更できる。データベース非依存
DB の種類に依存せず、置き換え可能である。外部エージェント非依存
ビジネスルールは、外界のインターフェ―スに関して知識を持たず、依存しない。
クリーンアーキテクチャは、これらの特性を統合したアーキテクチャである。
概要
クリーンアーキテクチャでは、システムの概念に境界線を引く。
この境界線が、それぞれが分離していることをより明確にし、疎結合なシステムを実現する。
下位の概念は、DB、UI、ウェブ等である。
通常、このレイヤーにはあまりコードを書かないようにする。なぜなら、このレイヤーには詳細が詰まっているためである。
GUI における MVC アーキテクチャ等も下位の概念である。外部サービスとのアダプターなども、このレイヤーに位置する。
上位の概念は、ビジネスルールを表現するエンティティ、アプリケーション固有のビジネスルールを含むユースケース、などである。
エンティティは、最も一般的で、最上位レベルのルールをカプセル化しており、外部で何か変化が起きても変化する可能性は低い。
ユースケースは、システムのユースケースがカプセル化され、実装されており、DB や、UI などの下位の変更を受けることがない。
依存性のルール
クリーンアーキテクチャを動作させる最も重要なルールは、依存性のルールである。
ソースコードの依存性は、内側(上位レベルの方針)だけに向かっていなければならない。
この説明は、クリーンアーキテクチャの同心円を説明するものだが、依存を 1 つの方向に限定し、常に上位の方針に向いている必要があるという事である。
外側(下位の概念)で宣言された名前を、内側(上位の概念)のコードで触れない。上位の概念は、下位の概念に影響を受けたくない。
依存性を管理するために
システムを構築する上で、上記のルールとは明らかに対立する依存関係も出てくる。この場合、依存関係逆転の原則(DIP)を使って解消する。
上位概念から下位の概念の具象に触れたい場合、インターフェースを呼び出すようにして、制御の流れとは反対のソースコードの依存関係を生み出すことが出来る。
上位概念が下位からデータを受け取る場合は？
概念の境界を超えるデータは、オブジェクトでも、ハッシュマップでも良いが、独立した単純なデータ構造であることが必要である。
ただし、上位概念にとって便利な形式にする。上位概念は、下位概念について深く知る必要がないためである。
テスト可能
ユースケースが中心となった外部要因に依存しないシステムアーキテクチャでは、フレームワークを使うことなく全てのユースケースのユニットテストを実行できる。
テスト実行のためにウェブサーバーやデータベースを起動する必要がない。
エンティティももちろん、単体でテスト可能である。
まとめ
クリーンアーキテクチャが一貫して実現しようとしているのは、依存性の管理と、それによるレイヤー間での疎結合の実現である。
自分自身最初に例の同心円を見た時、なかなか表現したい世界が理解できなかったが、シンプルなことを実現しようとしていることを理解できれば、より堅牢なシステムを構築できるようになるだろう。