難しすぎるし、説明が普通に下手 こんなもん人類には扱えない

• 簡単にまとめる

依存関係を制御する

• 依存関係を循環させないこと
• できるだけ抽象的な実装に依存し、詳細な実装には依存しないこと
• 使用側が実装側を考慮して条件分岐などをすることにならないこと

リスコフの置換原則

• 交換可能なパーツを使ってソフトウェアを構築する
• コンポーネント（≠ファイル）は単体で動作するようにし、それぞれが並行に開発できるようにする
  • ビジネスルール + npmモジュールやVSCodeのプラグインの様に使用できるようにすること
• 常に正しく動き、変更はコンポーネント内部で進め、正しく動くものを他に公開する

単一責任の原則

• モジュールを変更する理由（目的）は1つになること
  • 決して1つの機能というわけではなく、変更のステークホルダーを1つにするということ
    • （何のために変更するか）

モジュールの依存関係は「変わりやすいもの」が「変わりにくいもの」に依存する

• レベルが低いもの→レベルが高いものという依存に
  • 入出力から遠いほどレベルが高い
  • レベルが高いものは入出力やデバイスに依存しない
• 例
  • 最重要ビジネスルール（エンティティ）はソフトウェアであるか否か関係無く、最も変わりにくく、最も入出力からは遠く、レベルが高い
  • アプリケーション固有ビジネスルール（ユースケース）はエンティティをいつどの様に使用するかというもので、エンティティよりレベルが低い

エントリポイントの実装によって動作を変更できるようにする

• 通常mainと呼ばれるコンポーネントは最も下位（動作環境にのみ依存される）
• mainが上位レベルの方針に制御を渡すことで、開発用``テスト用``本番用などに簡単に分岐できる

ハードウェアに依存したファームウェア的コードと、プロダクトコードを分離する

• ハードウェアとそれに付随するファームウェアは変更されやすい
• ソフトウェアはそれ自体は長寿命だが、ハードウェアとファームウェアに破壊される可能性がある
• ファームウェアは一般の定義とは異なり、SQLやOS Native機能なども含める

クリーンアーキテクチャの費用対効果

• 一度実装した後に、継続してアップデートを重ねるようなケースでなかったり、個人開発で仕様を一人が完全に把握している場合、サービス自体が仮説検証中で激しく要件が変わる場合などは、Clean Architectureを導入するコストの方が大きく出ることがあるでしょう。
• 一方で要件がある程度明確な中、チーム開発で継続的にアップデートを続ける場合にはコストを上回るメリットを享受できるはずです。
• Clean Architecture を杓子定規に採用しなかったとしても、「変わりやすいものが変わりにくいものに依存する」という原則に則って、ビジネスルールをフレームワークから切り離すことにはメリットがある
• https://qiita.com/ttiger55/items/50d88e9dbf3039d7ab66

YANGIの法則との兼ね合い

• 無駄な抽象化は確かに良くないが、適切な境界を最初から設けることで回避できるコストも大きい