クリーンアーキテクチャ - 変更に強い境界設計

2026.06.14

公式ドキュメント
仕組み解説設計アーキテクチャクリーンアーキテクチャ

クリーンアーキテクチャとは、ビジネスルールをUI、データベース、フレームワークから切り離し、変更に強くするための設計思想です。

一言でいうと

クリーンアーキテクチャの中心は「外側の都合を内側に持ち込まない」ことです。

アプリケーションの中心には、業務ルールやユースケースがあります。Webフレームワーク、DB、HTTP、画面、外部APIは外側の詳細です。外側は変わりやすく、内側は長く残ります。

登場人物

層役割例
エンティティ業務上の重要なルールを持つ注文、請求、ユーザー
ユースケースアプリで実現する操作を表す注文する、支払いを確定する
インターフェースアダプター外部形式と内部形式を変換するController、Presenter、Repository実装
フレームワーク/ドライバ技術的な詳細Webフレームワーク、DB、UI

重要なのは、内側の層が外側の層を知らないことです。ユースケースが「PostgreSQLで保存する」と知っていると、DB変更の影響がユースケースへ入り込みます。

依存方向のルール

クリーンアーキテクチャでは、依存は外側から内側へ向きます。

Frameworks / Drivers
  -> Interface Adapters
    -> Use Cases
      -> Entities

外側のコードは内側を呼び出してよいですが、内側のコードは外側を直接呼び出しません。DB保存やメール送信が必要な場合は、内側にインターフェースを置き、外側で実装します。

処理の流れ

たとえば「注文を作成する」処理は次のように流れます。

順番処理責務
1HTTPリクエストを受け取るController
2入力をユースケース用の形に変換するAdapter
3注文作成の業務ルールを実行するUse Case / Entity
4保存インターフェースを呼ぶUse Case
5DBへ保存するRepository実装
6レスポンス用に整形するPresenter

この分け方にすると、HTTPではなくCLIから実行したい場合でも、ユースケースはそのまま使えます。

何がうれしいのか

  • UIを変えても業務ルールが壊れにくい
  • DBや外部APIを差し替えやすい
  • ユースケース単位でテストしやすい
  • フレームワークに依存しすぎない
  • 変更の影響範囲を読みやすい

特にテストでは効果が大きく、DBやHTTPサーバーを起動しなくてもユースケースを検証できます。

よくある誤解

層を増やせばクリーンになる

層が多いだけではクリーンになりません。重要なのは依存方向と責務の分離です。小さなアプリで無理に層を増やすと、ファイル移動だけが増えて読みにくくなります。

Repositoryを作れば完成

Repositoryは一部にすぎません。ユースケースが画面やDBの都合を知っているなら、Repositoryがあっても境界は崩れています。

フレームワークを使ってはいけない

フレームワークは使って構いません。ただし、業務ルールの中心にフレームワークの型やライフサイクルを置かないようにします。

向いている場面

向いている向いていない
業務ルールが複雑小さな一回限りのスクリプト
長く保守する画面だけの静的サイト
テストを厚くしたい試作品をすぐ捨てる
DBやUIの変更がありそう技術選定が固定で単純

導入チェックリスト

  • ユースケース名が業務の言葉になっているか
  • ユースケースがHTTPリクエストやDB接続を直接知らないか
  • エンティティに業務ルールが残っているか
  • Controllerに業務判断を書きすぎていないか
  • DBなしでユースケーステストを書けるか

まとめ

クリーンアーキテクチャは、コードをきれいに並べるための図ではなく、変更の影響を閉じ込めるための考え方です。

中心に置くべきものは、フレームワークではなく業務ルールです。依存方向を内側へ向けることで、外側の技術変更からアプリケーションの核心を守れます。

参考リソース

関連記事

おすすめ記事

← 一覧に戻る
PR
PR
PR
PR