MS_DependencyInversionPrinciple

依存性反転原則

• 戻る（IoC、AOP → DI → 依存性反転原則）
  • IoC
  • DI

概要

移動しました。

移行メモ（移動先の扱い）: 原文は本文を持たず、
「.NET開発基盤部会 Wiki」の同名ページへのリダイレクトのみである。
移動先の「依存性反転原則」は
dotnetdevelopmentinfrastructure サイト側のページで、
依存性反転原則 として移行済みである。

本ページは、IoC / AOP / DI からの
参照先として成立させるため、要点のみを以下に補って残す。

補足（依存性反転原則とは）: SOLID 原則の D にあたる設計原則で、
Robert C. Martin による定義は次の 2 点である。

1. 上位モジュールは下位モジュールに依存してはならない。
   どちらも「抽象」に依存すべきである。
2. 「抽象」は「詳細」に依存してはならない。
   「詳細」が「抽象」に依存すべきである。

【違反している例】

   業務ロジック（上位）
        │ 依存
        ↓
   SqlOrderRepository（下位・詳細）

   → DB を変えると上位まで壊れる
   → テストで DB を切り離せない

【依存性反転原則を満たす】

   業務ロジック（上位）
        │ 依存
        ↓
   IOrderRepository（抽象）
        ↑ 実装（依存の向きが反転している）
   SqlOrderRepository（下位・詳細）

   → 下位を差し替えても上位は無傷

「反転」しているのは依存の矢印の向きである
（下位 → 抽象、という向きに変わる）。
IoC が制御の流れの反転であるのに対し、
こちらは依存関係の反転を指す。両者は別概念である。

補足（抽象を「どこに置くか」が要点）: 実務でこの原則を
形骸化させてしまう典型が、インターフェイスの置き場所である。

×  Infrastructure プロジェクトに IOrderRepository を置く
      → 業務ロジックが Infrastructure を参照する
      → 結局、上位が下位に依存したまま

○  Domain（業務）プロジェクトに IOrderRepository を置く
      → Infrastructure が Domain を参照する
      → 依存の矢印が内向きに揃う

「インターフェイスは、それを使う側に置く」
というのが Clean Architecture / Onion Architecture の要点であり、
DI の「共通 I/F が無い場合」の議論とも同じ論点である。

なお、DI を使えば依存性反転原則を満たせる、わけではない。
具象クラスを注入していれば、依存の向きは反転していない。

	依存性反転原則	DI
種別	設計原則（何を目指すか）	実装技法（どう渡すか）
主眼	依存の向き	生成と利用の分離
無くても成立するか	DI 無しでも実現可（引数で渡す等）	DIP 無しでも DI は書ける

参考

Microsoft Learn

• アーキテクチャの原則（依存関係逆転）
  https://learn.microsoft.com/ja-jp/dotnet/architecture/modern-web-apps-azure/architectural-principles#dependency-inversion
• 一般的な Web アプリケーション アーキテクチャ（クリーン アーキテクチャ）
  https://learn.microsoft.com/ja-jp/dotnet/architecture/modern-web-apps-azure/common-web-application-architectures

---

Tags: 移行, プログラミング, .NET開発