この記事について
この記事は、 弁護士ドットコム Advent Calendar 2019 - Qiita の 18 日目の記事になります。
依存関係逆転の法則 (The Dependency Inversion Principle, DIP)
以前 Eureka Tech Blogの中で、SOLID 原則の D についての 依存関係逆転の原則の重要性について - Eureka Engineering という解説がありました。依存関係逆転についてコードも交えた実例としての説明があり非常に参考になるとともに、私の周りで議論が起こりましたので、それについて考察を行った結果を記してみたいと思います。
元となった記事での解説内容を簡単にまとめますと次のようなものです。(各図は元記事から引用)
以下のような Controller 
Service Repository という呼び出し関係があったとします。
図1
これに依存関係逆転(DIP)を適用すると
図2
となり、呼び出し元がインターフェースを規定することで、ServiceやRepositoryの実装に修正があった場合でも、呼び出し元では修正の必要がなくなります。
クリーンアーキテクチャとの対比
DIPの説明として
上位のモジュールは下位のモジュールに依存してはならない。
というものがあります。これを上の図に当てはめると、
上位: Controller, 下位: Service
上位: Service, 下位: Repository
というそれぞれの関係に対して、依存関係を逆転させたと考えられます。
ここで、上の構造をThe Clean Architecture との対比で見てみます。
図3
Repository はこの図においては Gateways に当たりますので、
Controller 及び Repository: Interface Adapters
Service: Application Business Rules(Use Cases)
という対応になると考えられます。
この同心円の図では外側が内側に依存するという関係があります。それを上位/下位で捉えると内側が上位ということになりますのでこの場合、
上位: Service
下位: Controller, Repository
という上下関係になり、クリーンアーキテクチャを取り入れる場合には、Serviceを上位とする構造を考える必要があるのでは?という議論が私の周りで起こりました。
再度の依存関係逆転
クリーンアーキテクチャーの観点から
上位: Service, 下位: Controller
として、図2の Controller と Service の依存関係を再度逆転させてみたものが次の図4です。
図4
やったことは、UserServiceInterfaceをControllerからServiceの方に移動したことで、こうしてみると、図3の右下にある図のPresenterの部分をRepositoryに置き換えたものと、同じ依存関係の図が得られました。
終わりに
弁護士ドットコムで提供しているクラウドサインではGoでバックエンドの開発を行っています。個人的な感想になりますが、Goは大変おもしろい言語だと感じています。
今回は考察をすすめるにあたってGoの実例を見ながら行ったのですが、おかげでGoのinterfaceおよびSOLID原則に対する理解が深まったと思います。今回の考察を行うきっかけになった記事を書かれたEurekaのrikiiさんに感謝いたします。さまざまな有益な情報を公開されていて非常に勉強になります。
さて、クリスマスまでまもなくですね。みなさま素敵なクリスマスをお迎えください。