blogリポジトリでDIをしてみて感じたこと
https://github.com/umaidashi/blog
（オブジェクト指向とかでいうドメイン層とか一旦無視して）上位の概念（今回は重要度が高いもの）が、わがままに自分が欲しい情報を定義し、その欲しい情報を渡す処理を実装する。渡す側は欲しい情報を満たしてさえいればいい
だからモデル（欲しい情報）が先に決まってテーブルができる 欲しい情報が手に入れば十分であるので、永続化をどこにするか、もしくは永続化するかどうかも、上位の概念は知る必要が無い
上位の概念は、わがままに欲しい情報を注文する。受注した下位の概念はその注文をみて情報を用意する
客と料理人の関係のように、客は欲しい食べ物を注文するが、それが出てくればよく、誰が作ろうが、いつ作ろうが、どこで作られようが問題がない
注意するのは、客が料理人を呼び出して直接注文するのではなく、注文用紙に書き込んで、注文用紙を経由して注文すること
プログラムでは、インターフェース（いわゆるリポジトリ層）を用意し（これが注文用紙）、そのインターフェース（注文）に沿った処理を実装する
インターフェースはメニューと言ってもいいかもしれない。客が見るメニューは、料理名と値段が書いてあり、料理人が見るメニューには、レシピや必要な材料、道具が書いてある。客は料理のレシピや必要な材料、道具に関心を持つ必要はなく、レシピを指示したり使う材料を指定する必要が無い。
DIしてない状態をレストランで表すなら、客が入店したら、厨房にある材料、設備を把握し、自分な食べたいものを事細かに指示する必要がある。また、別のレストランに行ったらまたそのレストランのことを知る必要がある。
DIされてる状態はフランチャイズのレストランが当てはまるかもしれない。裏の厨房の設備、配置や使ってる食材の産地は店ごとに違っても、客から見えるメニューはどの店舗でも同じであり、客視点では同じものとして扱える。