読書

[読書感想]なぜ依存を注入するのか DIの原理・原則とパターン

Sato Takeshi

12 2月 2026 • 4 min read

本記事にはAmazonアフィリエイトリンクが含まれます。

AIエージェントやVibe Codingが流行っています。プロンプトを打つだけである程度の実装はAIがやってくれます。
実装のコストは圧倒的に下がる時代になりました。
何を作るのかが決まりさえすれば、Claude Code、Cursor、Codex、Copilotその他が作ってくれます。

私はClaude Code派です。

しかし、コードをどう実装していくかという設計の部分はエンジニアがまだまだ担保しなくてはいけません。
ソフトウェアの開発は、一度作って終わりではなく、継続的な更新が求められるため、エンジニアとしても持続可能な開発が求められます。

「なぜ依存を注入するのか　DIの原理・原則とパターン (Compass Booksシリーズ) 」は持続可能な開発を進める上で重要な概念、依存性注入について余すことなく説明した解説本です。

ソフトウェアプロブラミングにおける設計に関して「依存性注入」と言う考え方は、古くから語られていますが、改めて取り入れた際の効果や、取り入れる場所や条件、何をするためなのか、そしてアンチパターンとかを全部全部書いたのがこの本です。
読んでいてとても楽しかったですね。
今までなんとなく断片的に、ブログなどで見聞きした概念が、全部まとまっていたのがよかったです。

本の内容としては第一章で「依存性注入」の概念を説明して、第二章でサンプルアプリケーションとしてECサイトのシステムを実装します。頑張って実装しましたが、密結合したシステムになってしまったので、第三章で疎結合にリファクタリングするというふうに話が進みます。

UI層、ドメイン層、データアクセス層にコードを分けても簡単に密結合してしまうシステムはできてしまうということが語られて、ありそうだなと思いました。
また「UI層をWebアプリケーションからWindowsアプリケーションに変えたい」や「データアクセス層をリレーションデータベースからAzure Table Storageに変えたい」などのありそうな機能開発があったりと、実際にありそうなケースに対してどうリファクタリングをしていくかを丁寧に解説しててすごく参考、関心するばかりでした。

ソフトウェアアプリケーションを設計する人は経験関係なく、この本を読めばみんな幸せになるんじゃないかと思います。

ともすれば抽象的な議論になりがちな設計の概念を、具体的なコードとともに解説して説得力がとてもある本でした。
具体的なコードは.Netアプリケーションでしたが、他のプラットフォームを開発している人にも有効と思います。
現に、私はiOS開発者ですが、依存性を取り入れる基準や場所などが書かれていたので、すぐにiOSの開発に活かせると思いました。

個人的に学んだこと

本書から学んだことを並べます。

インターフェイスを切るべき対象は「揮発性依存」を持つモジュールが対象
- 揮発性依存とは
  - 稼働させるために、実行環境の設定や調整が必要
  - まだ具象クラスが開発されてない機能
  - 対象の依存が開発に携わるすべての環境に用意されていない
  - 対象の依存に非決定的な振る舞いが含まれる（同じ入力に対して異なる振る舞いをする）
Decoratorパターン
- 現状の具象クラスと同じインターフェースを持ち追加の機能を持つクラス。ログの送信や監査証跡などシステムに横断的に行う機能を入れるときに使えr

依存性注入、プロトコルインターフェースを作ってそっちに依存させます。ここまでは良いとどこで実インスタンスを渡すのかなんですけど、プリケーションのトランスメインメソッドとか1番上位のところでしか渡してはいけない。それ以外で私と美空を見つ結合になるんでならばうまいでアプリケーション立ち上げますけど、まぁそこでガンガン使いたいインスタクラスのインスタンスを作って牛乳を渡していけばいいと渡された。スタン感じ。

後は後基準だ。何でもかんでもインターフェースプロトコル作ればいいわけではない基準があります。何を依存性として依存性注入として考えるのかには期限がありまして、依存性を注入して来なくて良いものはもうバイナリが固まってたりやること決まっているものインスタンス渡せばいいしてるんですけどまぁあとなんですかね。そういうのの方は文字列の方に対してマドラーインターレース切ってやるっていうのは、ほほほほ。ウェブアプリケーションでそこまで言わなくても思うのでなくてもいいとそれに対してまだ不安定なものという名前はと言う名称をしていたのか後で本で確認しますけれども不安定な使うか使わないかがまだはっきり決まっていない。そのアプリケーションとしてサービスとして決まってない。クラス機能はインターフェースに切りましょう。例えばデータベースの接続インスタクラス、具体的には、SQL SQLだったり、アジュールでクラウド化されて、クラウド化された後にノー式のものになったりとかDSじゃなくてねって言う可能性もある。依存性注入しなきゃだめだねって言う話だったりあとなんだ画面今ユーザに届ける画面で考えたけど、ウィンドウズのアプリケーションアプリケーションに

よってなった場合でも理想が変わらず層が変わるから、対応できるようにview以外のコードが変更しなくてもいいようなことですね。

to 後はアンチパターンですね。依存性をとってくるときに使いたい実インスタンスをどれ使えばいいのか判断。これをいい感じにそこも抽象化するって言う考えがあるんだけど、それはうまくいかないよって言う感じ。それ使うならツールを入れたほうがいいのかなと私は思いましたけれども、その依存させる実印の取得方法も抽象化すると、呼び出し側でもよくなる前提使い方の前提が露出しちゃったりするんで、良くないよって言う話がありました。

はい以上ですけれども、この本とってもオススメなので、アマゾンのリンク貼っときます。皆さんもなんか読むと楽しいと思います。ではまた