クリーンアーキテクチャ

クリーンアーキテクチャ

執筆済 ソフトウェア開発設計

依存の向きを、常に内側（抽象・安定）へ向ける構造。 Robert C. Martin が 2012 年に整理した。

        ┌──────────────────────┐
        │  Frameworks & Drivers │  UI, DB, Web
        │  ┌────────────────┐  │
        │  │ Interface      │  │  Controller, Presenter, Gateway
        │  │ Adapters       │  │
        │  │  ┌──────────┐  │  │
        │  │  │ Use Cases │  │  │  アプリ固有の業務規則
        │  │  │ ┌──────┐ │  │  │
        │  │  │ │Entity│ │  │  │  企業全体の業務規則
        │  │  │ └──────┘ │  │  │
        │  │  └──────────┘  │  │
        │  └────────────────┘  │
        └──────────────────────┘
              依存は内向きのみ

依存性のルール#

内側の円は、外側の円を一切知らない。

  • Entity は Use Case を知らない
  • Use Case は DB も UI も知らない
  • 外側が変わっても内側は変わらない

何を得るのか#

効果 内容
フレームワーク非依存 Web からモバイルへ移せる
テストできる UI も DB も無しで業務規則を検証できる
DB を後で決められる 判断を遅らせられる
外部サービスの差し替え 決済業者を変えても中心は変わらない

Martin の主張は 「アーキテクチャとは、決定を遅らせることを可能にする構造」。

境界を越える#

外側から内側を呼ぶには、 内側が定義したインタフェースを外側が実装する （依存性逆転）。

UseCase → UserRepository（内側で定義した抽象）
              ↑ implements
          PostgresUserRepository（外側の実装）

制御の流れは外から内、依存の向きは内から外。 この 2 つが逆であることが核心。

批判と現実的な運用#

批判 内容
コード量が増える 層ごとにモデルと変換が要る
小規模には過剰 ファイル数が機能数の何倍にもなる
DB を変えることは滅多にない 想定された利点が実現しない

「テストしやすさ」は現実的な利点だが、 「後で DB を差し替える」はほぼ起きない。

規模と寿命に応じて、 どこまで厳密にするかを決める。 中心（業務ロジック）だけを純粋に保ち、 周辺は素直に書く、という折衷が実務的。

参考文献#