クリーンアーキテクチャ再考 — 同心円の図ではなく、原則を読み直す

クリーンアーキテクチャの議論がまた盛り上がっている。この話題は数年おきに再燃するが、そのたびに同心円の図と「レイヤーを何枚切るか」の話に終始しがちだ。最近読んだクロパンダさんの読書ログが、あえて「クリーンアーキテクチャ」という言葉を使わずに原書の原則だけを整理していて良かったので、自分でも原書『Clean Architecture』の主張を2026年の環境で読み直してみた。

原書の主張は同心円ではない

原書が最初に置いているゴールは、システムの構築・保守に必要な人数を最小限に抑えることだ。ソフトウェアは「ソフト」であるべきで、変更コストが上がり続けるシステムは事業の足を引っ張る。同心円の図はそのための手段の一つの図解にすぎない。図をなぞることが目的化すると、変更を楽にするための設計で変更が大変になるという逆転が起きる。

凝集の3原則は「全部は満たせない」と書いてある

コンポーネントのまとめ方について、原書は3つの原則を挙げる。

REP（再利用・リリース等価の原則）: 再利用の単位とリリースの単位を揃える
CCP（閉鎖性共通の原則）: 同じ理由・同じタイミングで変更されるものをまとめる
CRP（全再利用の原則）: 依存するならそのコンポーネント全体に依存する

重要なのは、原書自身がこの3つは相反していて同時には満たせないと明言していることだ。開発初期はCCPを重視して「一緒に変わるものを一箇所に」まとめ、成熟してきたらREPに寄せて再利用単位を切り出す。モノレポでパッケージをどう切るかという現代の問題に、そのまま効く指針だと思う。初期からREP的にパッケージを細かく割ると、ひとつの機能変更が毎回複数パッケージにまたがるようになる。

依存の3原則は道具で機械的に守れるようになった

つなぎ方の原則 — 循環依存を避ける（ADP）、変わりやすいものから変わりにくいものへ依存する（SDP）、安定したものほど抽象にする（SAP）— は今も現役だ。むしろ現代の方が守りやすい。循環依存はESLintのimport/no-cycleやGoのパッケージ設計が機械的に検出してくれるし、UIからビジネスロジックへの一方向の依存はフレームワーク側の構造が後押ししてくれる。原則を知らずに道具だけ使っているケースも多いが、道具が何を守ろうとしているのかは知っておいて損がない。

「詳細の差し替え可能性」は目的が変わった

原書はUIやDBを「詳細」と呼び、簡単に差し替えられるべきだと説く。書かれた当時は、DBMSやフレームワークの乗り換えが実際に起きる長寿命システムが念頭にあった。しかし現代のWeb開発で、PostgreSQLを別のDBに差し替える日はまず来ない。「いつかDBを替えるため」の抽象化は、多くの場合割に合わない。前回書いたように、抽象化のためにRDBの能力を使わないのは本末転倒だ。

それでも境界を引く価値は残っている。ただし目的が変わった。

テスト容易性 — 境界があればテストダブルを差し込め、ビジネスロジックを高速にテストできる
構造から意図が見えること — ディレクトリを開いたときに、フレームワーク名ではなく業務が見えるか

原書のいうScreaming Architectureは後者の話で、rails-app/やspring-hibernate/ではなくaccounting/やinventory/が見える構造にせよという主張だ。これは今も、というより今の方が刺さる。

Package by Componentはモジュラーモノリスとして生き残った

原書の後半にある「ビジネスロジックと永続化をひとまとめにしたコンポーネント単位で切る」という選択肢は、レイヤーで水平に切るのではなく業務単位で垂直に切る発想だ。フロントエンドのfeatures/ディレクトリ、バックエンドのモジュラーモノリス — 名前を変えて現代の主流になっている。マイクロサービスに行く前の現実解として、一番使い出のある部分だと思う。

AI時代の読み方

レイヤーもボイラープレートもAIが数分で生成する時代になって、原則を「形」として適用するコストはほぼゼロになった。だからこそ、それぞれの原則が何のためにあるのかを理解して、目的が自分のシステムに当てはまらない原則を捨てる判断の方が重要になっている。

原書自身が「フェーズによって重視する原則を変えろ」と言っている。つまりこれは教条の本ではなく、トレードオフの本だ。同心円を写経するのではなく、相反する原則のどれを今の自分のプロダクトで優先するかを決める — それが2026年に読むクリーンアーキテクチャとして、一番実りのある読み方だと思う。