【ITニュース解説】Clean Architecture: The Four Concentric Circles Explained

ソフトウェア開発において、システムが複雑になるのは避けられない現象だ。時間が経つにつれて、コードの塊は扱いにくくなり、新しい機能の追加は難しく、既存のバグの修正も手間がかかるようになる。さらに、テストがしにくくなったり、全体のメンテナンスコストが跳ね上がったりといった問題も生じる。このような課題に対処するための強力な設計思想が「Clean Architecture（クリーンアーキテクチャ）」である。これは、ソフトウェアの核となるビジネスロジックを、フレームワークやデータベース、ユーザーインターフェース（UI）といった具体的な技術的な詳細から完全に独立させることを目指すものだ。このアプローチにより、アプリケーションは技術の進化に合わせて柔軟に対応でき、保守しやすく、テストしやすい状態を保つことができる。

Clean Architectureは、アプリケーションを明確で独立した層に整理するソフトウェア設計の哲学である。その主要な目的は、アプリケーションの中核となるビジネスルールを、データベースの選択、使用するWebフレームワーク、またはユーザーインターフェースの実装方法といった「実装の詳細」から分離することにある。この分離を徹底することで、例えば、使用しているデータベースを別のものに交換する際に、アプリケーションのビジネスロジックに一切変更を加える必要がなくなる。また、特定のWebフレームワークに依存せず、システム全体を書き直すことなくフレームワークを入れ替えることも可能になる。さらに、アプリケーションの最も重要な部分であるビジネスルールを、遅くて不安定になりがちな外部システムに依存することなく、高速かつ安定してテストできるようになるのも大きな利点だ。

Clean Architectureの構造は、4つの同心円として視覚的に捉えることができる。それぞれの円は特定の責任を持つ層を表している。

最も内側の円は「Entities（エンティティ）」だ。この層は、アプリケーションのコアとなるドメインモデルと、それに関するビジネスルールを含む。例えば、ECサイトであれば「商品」や「注文」といった概念そのものや、それらが持つべき最低限の条件（例：商品の価格は負の値にならない）がこれにあたる。エンティティは、特定のフレームワーク、データベース、またはライブラリに一切依存しない。そのため、非常に安定しており、複数のアプリケーションで再利用できる設計になっている。

次に内側から2番目の円が「Use Cases（ユースケース）」である。この層は、アプリケーションがユーザーからの入力や外部イベントに対してどのように応答するかを定義する。例えば、「商品をカートに追加する」や「注文を確定する」といった、具体的なアプリケーションの機能や操作の流れがユースケースにあたる。ユースケースは、エンティティとビジネスルールを連携させる役割を果たす。この層は、Web画面のレイアウト、UIの特定の要素、またはデータベースの具体的な実装方法といった詳細については一切関知しない。

内側から3番目の円は「Interface Adapters（インターフェースアダプター）」である。この層は、コントローラー、プレゼンター、ゲートウェイ、マッパーといった要素を含む。その名の通り、この層の役割は、外部システム（例えば、WebブラウザからのHTTPリクエスト、データベース、他の外部サービスなど）と、内側のエンティティやユースケースの層との間でデータを「適応（アダプト）」させることだ。具体的には、外部から受け取ったデータを、アプリケーションのコア部分が理解できる形式に変換し、またコア部分から受け取ったデータを外部システムが理解できる形式に変換して出力する。

そして最も外側の円が「Frameworks & Drivers（フレームワークとドライバー）」である。この層には、データベースシステム、Webアプリケーションフレームワーク、ファイルシステム、ネットワークサービス、UIフレームワークなど、具体的な技術的な実装や外部ツールが含まれる。これらはアプリケーションの本質ではなく、「詳細」として扱われる。この層のコンポーネントは、アプリケーションのビジネスロジックに影響を与えることなく、必要に応じて交換できる。

Clean Architectureが重要視される理由は多岐にわたる。まず、「関心の分離」が徹底される点だ。各層がそれぞれ特定の役割に集中するため、システム全体が理解しやすく、保守や機能拡張が格段に容易になる。次に、「テスト容易性」がある。ビジネスルールはデータベースやWebフレームワークといった外部システムから完全に分離されているため、非常に高速かつ独立してテストできる。これにより、開発の初期段階で問題を発見しやすくなる。さらに、「柔軟性」が高いことも大きな利点だ。アプリケーションのコアロジックを変更することなく、Webフレームワーク、データベース、またはUIレイヤーといった技術的な詳細を自由に入れ替えることが可能になる。これは、将来的な技術の陳腐化や要件の変更に強いシステムを構築する上で非常に有利だ。最後に、「スケーラビリティ」も向上する。明確な構造と分離により、システムの成長や新しいシステムとの統合が、既存の構造を損なうことなくスムーズに行える。

具体的な例として、Javaのコードを使ってClean Architectureの原則がどのように適用されるかを見てみよう。

「Domain Object - Entities」の例として示されているAthleteクラスは、まさにエンティティ層の核となる部分だ。これは、アスリートのID、名前、年齢、カテゴリーといった、アスリートという「ビジネス上の概念」が持つべきデータとその基本的な振る舞いを定義している。このクラスは、特定のデータベース技術（例：SQLデータベース、NoSQLデータベース）やWebフレームワーク（例：Spring Boot）に一切依存していない。これは、純粋なビジネスの概念であり、どんな技術環境でも普遍的に利用できる。

次に「Use Case - Input Port」のAthleteInputPortインターフェースは、ユースケース層への「入り口」となる契約を定義している。これは、「アスリートを取得する」「アスリートを作成する」「アスリートを更新する」といった、アプリケーションが提供するべき機能の一覧だ。このインターフェースは、これらの操作を外部に公開するが、その具体的な実装方法や、データがどこに保存されるかといった詳細については一切関知しない。

「Use Case - Output Port」のAthleteDaoOutputPortインターフェースは、ユースケース層から外部への「出口」となる契約を定義している。これは、ユースケースがデータを永続化（保存）したり、取得したりする際に、どのような操作を「外部に期待するか」を記述したものだ。例えば、「IDでアスリートを取得する」といった操作がある。ユースケースは、このインターフェースを通じてデータアクセスを行うため、実際にどのデータベースが使われているかを知る必要がない。

そして「Use Case Implementation」のAthleteUseCaseImplクラスは、AthleteInputPortインターフェースを実装し、具体的なビジネスロジックを実行する。このクラスは、AthleteDaoOutputPortを通じてデータの永続化層とやり取りをするが、具体的なデータベースのコードは書かない。つまり、アスリートに関するビジネスルールや操作の手順を定義しているだけで、UIやDBの実装詳細には触れない。

「Interface Adapters – Controller」のAthleteControllerクラスは、Webアプリケーションの文脈では、Webリクエストを処理するコントローラーだ。これは、外部（例えばWebブラウザ）からHTTPリクエストを受け取り、そのデータ（例：アスリートのIDや新しいアスリートの情報）を、内側のユースケース（AthleteInputPort）が理解できる形式に変換して渡す。また、ユースケースからの結果を、Webレスポンスに適した形式に変換して返す役割も担う。ここでは、Spring Frameworkの@RestControllerや@RequestMappingといったアノテーションが使われているが、この層はユースケースとは直接的な依存関係を持たず、変換役として機能する。

最後に「Frameworks & Drivers – DB」のAthleteDaoImplクラスは、AthleteDaoOutputPortインターフェースを実装し、実際のデータベース操作を行う。この例では、AthleteRepositoryという特定のデータベースアクセス技術（おそらくSpring Data JPAのようなもの）を利用して、アスリートデータの永続化（保存や取得）を実現している。このクラスは、具体的なデータベースの技術的な詳細を扱う最も外側の層であり、AthleteDaoOutputPortという契約の背後にその実装詳細を隠すことで、ユースケース層がデータベースの実装に依存しないようにしている。

Clean Architectureを適用することで、コアなビジネスロジックは特定の技術的な詳細から完全に切り離され、アプリケーションの各部分の責任が明確に分離される。これにより、フレームワークやツールを交換してもビジネスの核となる部分を書き直す必要がなく、非常に柔軟で、保守しやすく、テストしやすいシステムを構築できる。このようなシステムは、要件の変化や技術の進化に迅速に対応できるため、長期的に安定して運用できるのだ。速く進む唯一の方法は、物事を「正しく」行うことであるという原則に基づいている。