この5つのルールの根幹には「円の内側は円の外側を呼び出さない」という「依存性のルール」が存在しており、このルールこそがClean Architecture最大の特徴といえます（図1）。「依存性のルール」があることで円の内側と外側で独立して実装できるため、DBを「Oracle」から「MySQL」に変えたり、UIを変更したりといったことが容易になり、さらにテストもそれぞれ独立して実行できるという利点があります。

　一方、Clean Architectureは細かく役割を刻むため、他のアーキテクチャと比べるとコード量は多くなる傾向にあります。特に、各レイヤー間はインタフェースを定義して実装と呼び出しの依存関係を分離するため、それなりの労力が必要になります。そのためスマートフォンアプリなどの小規模なソフトウェア開発にはあまり向いておらず、ビジネスアプリケーションのように比較的大規模なソフトウェア向けといえるでしょう。

画像をご覧いただくには会員登録が必要です

会員登録・ログイン

図1　Clean Architectureのイメージ（出典：The Clean Architecture）

「テスタビリティー」から考えるClean Architecture

　Clean Architectureは、「テスト可能性」をルールの一つとして定義しているほどテストのしやすさを重視しているアーキテクチャです。特に「円の内側は円の外側を呼び出さない」という「依存性のルール」は、テストの際に非常に重要です。とはいっても、実際にはどうしても円の内側から外側を呼ばなければならないケースもあるでしょう。その場合でもClean Architectureはあくまでもルールに忠実で、決して円の内側から外側を直接呼ぶことはしません。

　実は、マーティン氏はそういったケースも想定して対策を示しています。もう一度、Clean Architectureのイメージ図を見てみましょう。

画像をご覧いただくには会員登録が必要です

会員登録・ログイン

図2　Clean Architectureのイメージ（出典：The Clean Architecture）

　イメージ図の右下（図2の点線部分）に示されているように、例えば内側の「ユースケース」から外側の「プレゼンター」を呼び出す場合は、ユースケースの内側にある「ユースケース出力ポート」を呼び出します。そして、この「ユースケース出力ポート」の実装をプレゼンター側で用意することにより、結果的に円の内側から外側の呼び出しを実現します。

　このように書くと“とんち”で解決したように聞こえますが、実はこれが依存性のルールを実現するための重要なテクニックなのです。テストの観点からも、責任の分離の観点からも、この実装方法は非常に有効な方法だというのが最近改めて認識されています。

　Clean Architectureをプロジェクトに適用すべきかどうかは、プロジェクトの規模やソフトウェアの性質にもよりますが、Clean Architectureの概念の中には汎用的に使えるものがたくさんあるので、プロジェクトで活用してみてはいかがでしょうか。

テストに強いアーキテクチャとは？

　連載5回を通して「MVP」「MVVM」「Flux」「Clean Architecture」と4つのアーキテクチャを紹介してきましたが、本連載のテーマである「テストに強いアーキテクチャ」は一体どれなのでしょうか。私が思うに「テストのしやすさ」という視点では、すばりClean Architectureだと思います。先にも述べたように、アーキテクチャのルールとして“テストのしやすさ”を定義しており、ここまでテストを考慮したアーキテクチャは他にはありません。

　ただし、Clean Architectureはコード量も多く比較的労力がかかるアーキテクチャです。テストがしやすいからといって安易にClean Architectureを選ぶのは避けた方が良いでしょう。ソフトウェアの種類や規模によって使い分けるのがベストです。そういう意味で、個人的には、以下のような使い分けが一番良いのではないかと考えています。

画像をご覧いただくには会員登録が必要です

会員登録・ログイン

表2

　個人的にアーキテクチャはもう出そろったと感じています。新たなアーキテクチャが生まれるまではこの4つを用途と規模に応じて使い分けていくのが良いのではないでしょうか。