クリーンアーキテクチャ：依存関係ルールとライブラリ/フレームワーク
Robert C. MartinによるClean Architecture では、依存関係のルールは、最も外側のレイヤー/リングから最も内側のリングまでを厳密に指しています。
例として、Dependency Injection Frameworkは、最も外側のレイヤー（フレームワーク）に配置して、置き換えられるようにする必要があります。
ただし、属性に依存するDIフレームワークは、これらの属性を必要とするすべてのクラスがフレームワークに依存するため、これを明確に破ります。したがって、このようなライブラリーは、依存関係の規則に従って厳密に使用することはできません。
ユーティリティライブラリで同じ問題が発生しています。数学ライブラリまたはIObservables/Subjectsを提供するRxライブラリ。
数学ライブラリは、交換可能に保つためにアダプターでラップすることができます。これは理にかなっていますが、たとえば、エンティティ（ほとんどのレイヤーの内部）とシステム（ビジネスルール）の両方にフレームワークを提供するエンティティ、さらにはUI（プレゼンター）このデザインではうまくいきません。
ただし、数学ライブラリの場合でも、依存関係の反転+アダプターのインターフェイスを追加するコストは非常に異常に聞こえます。
私は何かを見逃していますか、これは多かれ少なかれルールであり、Clean Architectureを実装しようとすると一般に違反します。
あなたの観察は正しいです。ただし、これは「クリーンアーキテクチャ」アプローチが一般的に間違っていることを意味するものではありません。
データベースレイヤーやネットワークレイヤーなどの「外部リング」からビジネスロジックを切り離す1つの主要な手法は、依存性注入です。これは、システムを、DIフレームワーク自体（使用している場合）以外の多くのテクノロジから切り離すのに役立ちます。 DIを適用してシステムをDIフレームワークから切り離すことはできません。このような依存関係を避けたい場合、唯一の方法は、DIフレームワークをまったく使用せず、 Pure DI に固執することです。
ただし、数学ライブラリの場合でも、依存関係の反転+アダプターのインターフェイスを追加するコストは非常に異常に聞こえます。
はい、抽象化と分離の利点は常に代償を伴います。そのため、使用しているすべてのサードパーティライブラリまたはツールまたは外部システムについて、それをシステムの「インフラストラクチャ」として直接使用する場合のコスト/メリットの関係を評価するか、抽象化レイヤーを提供する必要があるかどうかを評価する必要があります。
優れたリトマステストはユニットテストです。追加の抽象化レイヤーなしで、ソフトウェアの高速でシンプルなユニットテストを作成できますか？
数学ライブラリの場合、答えはおそらく「はい」です->デカップリングは面倒の価値がないかもしれません
データベース層の場合、答えは多くの場合「いいえ」になります->デカップリングはおそらく価値があります
このアプローチは、システムのどの部分を「クリーンアーキテクチャ」に固執し、どの部分を無視するかを決定するのに役立ちます。
クリーンアーキテクチャのポイント は、アプリケーションのテクノロジを簡単に置き換え可能にすることです。これは 変化するビジネスロジックを高価にするコスト です。
したがって、ビジネスロジックの変更（つまり、ビジネス価値の提供）がテクノロジーの変更よりも可能性が高いアプリケーションを実行している場合は、クリーンアーキテクチャのアイデアを完全に無視することをお勧めします。
そうは言っても、私は依存性注入フレームワークのファンでもありません。通常はデザインに干渉するため、実際にはアプリケーションから完全に除外します。