ブログ記事

アーキテクチャとは「依存の方向」の問題だ：Robert C. Martin『Clean Architecture』

著者: DevBookPath 編集部公開日: 2026-06-10

「アーキテクチャが良い」とはどういう状態を指すのか——この問いへの答えは意外なほど具体的に示せる。Robert C. Martin（Uncle Bob）の『Clean Architecture 達人に学ぶソフトウェアの構造と設計』は、その答えを「依存の方向」という一つの軸に収束させた一冊だ。

1. アーキテクチャの目的は「オプションを残すこと」

本書が冒頭で述べるアーキテクチャの目的は、機能の実現ではなく「決定を先送りできる余地を作ること」だ。

データベースを MySQL にするか PostgreSQL にするか、フレームワークを何にするか——これらの決定が早い段階でコアのビジネスロジックに影響を与えてしまうと、後から変更するコストが跳ね上がる。良いアーキテクチャとは、これらの技術的選択を「後で決めても動く」状態に保つ設計だ。

この観点では、データベースやフレームワークはアーキテクチャの中心ではなく、交換可能な「詳細」として扱われる。

本書の中核となる原則が「依存の方向ルール（Dependency Rule）」だ。

ビジネスロジックは外側の技術的な詳細を知らない。逆に、外側のレイヤーは内側に依存する。同心円で表すなら、エンティティ（最内側）→ユースケース→インターフェースアダプタ→フレームワーク/ドライバ（最外側）という順序で、依存の矢印は常に内側に向かう。

これが守られることで、フレームワークやDBを変更しても、ビジネスロジックを表すエンティティとユースケースには手を入れずに済む。「ビジネスルールを変えたいのにDBのコードを読まなければならない」という状況が、この原則の違反から生まれる。

本書はSOLIDの各原則を改めて「コンポーネントレベル」と「アーキテクチャレベル」で解説している。

なかでも重要なのが依存関係逆転の原則（DIP）だ。具象クラスではなく抽象に依存するという原則は、レイヤー間の境界線でも機能する。内側のユースケースが外側のDB実装に直接依存するのではなく、内側が定義したインターフェースに外側が依存することで、依存の方向が逆転する。

境界線はこの逆転を実現する設計上の装置だ。何を境界線の内側に置き、何を外側に置くかが、アーキテクチャの大半の判断を占める。

本書の中で印象に残る概念として「叫ぶアーキテクチャ」がある。コードベースのディレクトリ構造や依存関係を見たとき、それがシステムの「機能」（例：受注管理システム、医療記録システム）を叫んでいるか、それともフレームワーク（例：Railsアプリ、Springアプリ）を叫んでいるか、という問いだ。

後者の状態では、ビジネスロジックがフレームワークの都合に埋没しており、本質的な問題領域がコードから読み取りにくい。フレームワークは実装の詳細であり、アーキテクチャの主役ではないという主張はここにも通じている。

この本の前後の読書順は、DevBookPath のグラフで確認できます。

本記事のリンクには Amazon アソシエイト等の広告が含まれる場合があります。リンク経由の購入で運営者に紹介料が支払われることがあります。

この地図を共有