ソフトウェアアーキテクチャの集大成「Clean Architecture」とは

5回にわたって各ソフトウェアアーキテクチャの特徴について解説した。結局、テスタビリティ―のあるアーキテクチャはどれなのか。連載最終回となる本稿で、テストに強いアーキテクチャについて説明する。

» 2020年03月18日 08時00分公開

[石黒邦宏，デジタルハーツ]

　ソフトウェア開発においてさまざまなアーキテクチャが提案されている中で、テストに強いアーキテクチャを紹介する本連載ですが、第5回の本稿では、「Clean Architecture」（クリーンアーキテクチャ）について解説します。

著者紹介：石黒邦宏

デジタル・マジック・ラボでインターネット経路制御運用に関わり、オープンソースウェアで経路制御を実現する「GNU Zebra」を開発。1999年IP Infusionを共同設立し、CTOに就任。2009年Access CTO、2015年アプリックス CTOを経て、2018年デジタルハーツホールディングスCTOに就任。

「Clean Architecture」とは？

　Clean Architectureはロバート・C・マーティン氏が提唱したアーキテクチャです。マーティン氏は「アンクルボブ」という通称でも知られている著名なエンジニアで、「Manifesto for Agile Software Development」（アジャイルソフトウェア開発宣言）の著者の一人でもあります。また、その他数々の著作でも知られており、現在、多くの人から尊敬されているエンジニアの一人といえるでしょう。

　Clean Architectureが書籍で発表されたのは2017年9月。そのため比較的新しいアーキテクチャだと思われがちですが、最初にマーティン氏がブログ記事でClean Architectureに関する記事を書いたのは2012年8月であり、実は意外と古い概念です。

　2012年当時は、「MVC」と「MVP」の後継にあたるアーキテクチャとして「Hexagonal Architecture」（ヘキサゴナルアーキテクチャ）や「OnionArchitecture」（オニオンアーキテクチャ）などが多数提唱されていました。マーティン氏は、「これらのアーキテクチャには共通点があるのではないか。その共通点を1つにまとめれば汎用（はんよう）的なアーキテクチャができるのではないか」と考え、Clean Architectureの構想を思い描きました。そういう意味では、Clean Architectureは、MVCから始まったソフトウェアアーキテクチャの集大成の一つといえるでしょう。

　マーティン氏のユニークな点は、Clean Architectureの議論に入る前に、まずは“アーキテクチャ”自体の存在意義を明確に定義したことです。

「ソフトウェアアーキテクチャの目的は、求められるシステムを構築・保守するために必要な人材を最小限に抑えることである」

「必要な労力が少なく、システムのライフタイム全体で低く保たれているならば、その設計は優れている。逆に、リリースごとに労力が増えるなら、その設計は優れていない。ね、簡単でしょ」

出典: Robert C.Martin,角征典,高木正弘. Clean Architecture　達人に学ぶソフトウェアの構造と設計 (Japanese Edition)

　「コスト・労力を最小限に抑える＝アーキテクチャの存在意義」マーティン氏は言い切っています。これ以上明確な定義はないのではないかというくらいはっきりしていますね。

　さらに、Clean Architectureには明確なルールが決められています。アーキテクチャにまつわる議論では、しばしば形式主義に陥り本質を見失いがちになりますが、Clean Architectureは構成の是非よりも原則やルールを定義し、そのルールにのっとってさまざまな議論ができるようになっています。

　Clean Architectureで提唱されている主なルールは以下の5つになります（表1）。

表1

　この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を選ぶのは避けた方が良いでしょう。ソフトウェアの種類や規模によって使い分けるのがベストです。そういう意味で、個人的には、以下のような使い分けが一番良いのではないかと考えています。