🐡
【15分で学ぶ】クリーンアーキテクチャ入門 #2
クリーンアーキテクチャの核心
前回の記事では、ソフトウェアが抱えがちな課題の根源に
「関心事の混在」 があることを見ました。
今回は、クリーンアーキテクチャがその課題をどのように解決するのか、
その核心となる考え方に迫ります。
有名な「あの図」が全てではない
クリーンアーキテクチャと聞くと、多くの人が次のような同心円の図を思い浮かべるでしょう。
しかし、重要なのはこの4つの層の名前を暗記することではありません。
この図はあくまで実装の一例です。
本当に理解すべきは、この図が示そうとしている
「根源的な原則」 のほうです。
本当の目的： 「重要なもの」と「重要でない詳細」の間に境界を引く
クリーンアーキテクチャの真の目的は：
ビジネスにとって重要なもの（ポリシー）と、それ以外の重要でないもの（詳細）との間に、明確な境界線を引くこと
ソフトウェアは次の2種類に分類できます：
| 種類 | 説明 | 例 |
|---|---|---|
| 重要 | ビジネスの本質的なルール | 料金計算ロジック、在庫ポリシー、ユーザー権限など |
| 詳細 | 実装のための技術的な要素 | Webフレームワーク（Rails, Next.js） DB（MySQL, PostgreSQL） UIなど |
- ビジネスの本質的なルール = 事業の根幹
- 技術的な詳細 = ビジネスの実装手段
クリーンアーキテクチャでは、これらが互いに影響を与えないように分離することが重視されます。
最重要原則：依存性のルール
(The Dependency Rule)
この境界線を守るための絶対的なルールが
「依存性のルール」 です。
ソースコードの依存の方向は、必ず 詳細 → ポリシー に向かわなければならない。
言い換えると：
- 重要なビジネスルールは、重要でない詳細を「知らない」
例：
-
PriceCalculator（料金計算ロジック）は、
自分がReactコンポーネントから呼ばれていることを知らない。 -
User（ユーザー情報）は、
自分がMySQLに保存されることを知らない。
つまり、ビジネスのポリシーは技術的詳細から完全に独立しているべきなのです。
❌ 逆方向の依存は許されません！
Next
「重要なビジネスルールが、データベースという詳細を知らないのに、どうやってデータを保存するの？」
そんな疑問が湧いてくるかもしれません。
その疑問を解決する鍵が、次の章で解説する
「依存性逆転の原則（Dependency Inversion Principle）」 です。
Discussion