クリーンアーキテクチャ とは？

DBやUI、フレームワークの詳細が変わったとき、ビジネスルールへの影響を抑えるためだよ。内側を独立させれば、外部ツールなしでルールをテストしやすくなる。ただし移行が差し替えだけで必ず済むわけではなく、境界の実装や互換性の確認は必要なんだ。

代表的な図では、内側からEntitiesが一般的なビジネスルール、Use Casesがアプリ固有のルール、Interface Adaptersがデータや呼び出しの変換、Frameworks & DriversがDBやWebなどの詳細を担うよ。4という数は模式的で、必ず四つの層やフォルダーに分ける規則ではないんだ。

目的と負担を見て境界を設計しよう。層の数や名前をそろえるより、内側のコードが外側の具体的な型や名前を参照しないことが中心のルール。HTTPやDB固有のデータをそのまま内側へ持ち込まず、内側に合う形へ変換するんだ。

内側で定めたインターフェースを外側の実装が満たすようにすれば、実行時には外へ処理を渡しても、コードの依存は内向きにできるよ。「外から内へ」は実行順の制限ではないんだ。ヘキサゴナルなどにも関心を分ける共通の目的があるけど、細部まで同じ設計という意味ではないよ。