🐕

【15分で学ぶ】クリーンアーキテクチャ入門 #4

に公開

まとめ

✅ クリーンアーキテクチャの要点まとめ

アーキテクチャの目的は「保守コストの最小化」

  • 良いアーキテクチャは、将来の機能追加や仕様変更を最小の労力で実現することを目指します。

課題の根源は「関心事の混在」

  • 重要なビジネスルール(ポリシー)
    重要でない実装の詳細が混在することで、
    ソフトウェアは
    硬く・脆く
    なります。

解決策は「境界を引いて、依存を制御する」こと

  • ポリシーと詳細の間に明確な境界線を引き、
    依存関係の方向を一方通行にすることが重要です。

最重要ルールは「依存性のルール」

  • 依存関係は常に「詳細 → ポリシー」に向かうべき

実現の鍵は「依存性逆転の原則(DIP)」

  • **インターフェース(抽象)**を間に挟むことで、
    処理の流れとは逆向きの依存関係を構築し、境界を守ります。

✅ クリーンアーキテクチャのメリットと注意点

👍 メリット

  • テスト容易性
    → ビジネスロジックをUIやDBから分離できるため、単体テストが容易に。

  • 保守性
    → 変更の影響範囲が境界の内側に留まるため、修正がしやすい。

  • 技術選定の柔軟性
    → DB・フレームワークの交換が容易になり、ビジネス要件に応じた最適な選択が可能。


⚠️ 注意点

  • コード量の増加
    → 抽象(インターフェース)導入により、ファイル数やコード量が増えがち。

  • 過剰設計のリスク
    → 小規模なプロジェクトやプロトタイピングでは、過剰な構造になる可能性も。


✍️ 個人的感想

クリーンアーキテクチャは、有名な同心円の図ばかりが一人歩きして誤解されている書籍だと感じています。

重要なのは図に従うことではなく、考え方を理解すること。

要は、高凝集・疎結合 を実現するための思想であり、構えすぎる必要はありません。

同心円の図に合わないシステムも多く存在します
(例:Rails、ゲームエンジン、フロントエンドFWも相性悪いかも)

→ それでも原則は応用可能であり、どんなシステムにも取り入れる価値はあります。

余談ですが、書籍内でのOOPについての解説がありますが、個人的には反論の余地があると感じています。


以上!

Discussion