りゅうじの学習blog

学習したことをアウトプットしていきます。

5/25 ドメイン駆動設計 Chapter7 7-3

7-3 依存関係逆転の原則とは

依存関係逆転の原則(Dependency Inversion Principle)は以下のように定義される

    1. 上位レベルのモジュールは下位レベルのモジュールに依存してはならない、どちらのモジュールも抽象に依存すべきである。
    1. 抽象は、実装の詳細に依存してはならない。実装の詳細が抽象に依存すべきである。

ソフトウェアを柔軟なものに変化させ、ビジネスロジックを技術的な要素から守るのに欠かせないものです。

7-3-1 抽象に依存せよ

  • プログラムにはレベルと呼ばれる概念がある
    • 入出力からの距離を示す
      • 低レベルは機械に近い具体的な処理
      • 高レベルは人間に近い抽象的な処理
        • 依存関係逆転の原則で出てくる低レベル・高レベルはこれと同じ
  • 例として、UserRepositoryの処理は、UserRepositoryを操作するUserApplicationServiceよりも機械に近い処理
    • レベルの概念で言うと、下位レベルがUserRepositoryであり、上位レベルが、UserApplicationServiceとなる
      • 抽象型であるインターフェースを使用しないと、上位レベルのモジュールが下位レベルのモジュールに依存している原則に反する行為である

図で言うと、この状態が依存関係逆転の原則での、上位レベルのモジュールは下位レベルのモジュールに依存してはならない、どちらのモジュールも抽象に依存すべきである。に則って、修正である。

  • 元々、具体的な実装に依存していたものが抽象に依存するようになり、依存関係は逆転しました
  • 一般的には、抽象型はそれを利用するクライアントが要求する定義です
    • IUserRepositoryはUserRepositoryのために存在していると言っても過言ではない
      • インターフェースという抽象に合わせて実体クラスを実装することは、方針の主導権をUaesrApplicationServiceに握らせることと同義である
        • 抽象は、実装の詳細に依存してはならない。実装の詳細が抽象に依存すべきである。という原則がこのように守られる

7-3-2 主導権を抽象に

  • 伝統的なソフトウェア開発手法では、高レベルなモジュールが低レベルなモジュールに依存する形で作られる傾向があった
    • 抽象が詳細に依存する形の構成ということ
      • これだと低レベルのモジュールの方針の変更が高レベルのモジュールに波及する
        • 重要なドメインのルールが含まれるのは高レベルのモジュールなので、これはおかしな状態である
        • 例えば、データストアの変更を理由にビジネスロジックを変更することは起きてほしくない
  • 主体となるべきは、高レベルなモジュール=抽象である
    • 高レベルなモジュールは低レベルなモジュールを利用するクライアントです
      • クライアントすべきはどのような処理を呼び出すかの宣言
        • インターフェースはそれを利用するクライアントが宣言するものであり、主導権はクライアントにある
          • インターフェースを宣言し、低レベルのモジュールはそのインターフェースに合わせて実装することで、より重要な高次元の概念に主導権を握らせることが可能になる

コメント

依存の話を恋愛に例えると

特定の異性を好きになるのではなく、抽象クラスであるインターフェースを作って、その型に当てはまる実体の異性を探すことで、特定の個人に依存しないでいられるって事だと思いました。

  • 自分をクライアントとし、お相手を低レベルなモジュールとした場合(ひどいやつだ笑)お相手の一挙一動に振り回されないようにするために、特定の個人に依存してはならない。
    • 自分には、大事なドメインのルール(人生の指針)があるため、こちらが重要なもの。
      • これを低レベルなモジュールに脅かされないようにするために、好みのタイプというインターフェースに沿った個人を見つける
      • 自分はインターフェースに依存しても構わないが、特定の個人に依存することは、原則に反する行為なのであってはならない。

参考

ドメイン駆動設計入門 ボトムアップでわかる!ドメイン駆動設計の基本