SOLID原則のD、「Dependency inversion principle」だが個人的にはClean Architectureを読んで理解が深まったように感じている。単体のクラス設計にとどまらず、パッケージ単位で見たらどうなる？という話も含まれるが、「どのくらいズームイン/ズームアウトしようと、依存の流れをどうしたいかという意思は同じだろう」と思う。
ざっくりいうと「お前がどう使われたいかはお前自身がハッキリ定めておけよ！！」という。 これは「組織」というパッケージだったり、「個人」という単体コンポーネントだったりにも適用できるのではないか？などと思った。
表面的に考えると、「人は組織に所属する」ということで、これは集約ないしコンポジットと考える。所有もしくは部分と言う関係だ。「人: 組織の一部」。
また、「組織は人に依存する」ということになる。
組織全体での期待が、具体的には「他の個人」からの依存という形で現れたり、単に「組織-役割-個人」という関係性の中に規定されていたりする。
パッケージの外部に「私はこういう約束を満たします」というのをInterfaceとして定義して、外の奴らはそのInterface=取り決めに従ってメッセージを送りあえ、というのがClean Architectureで語られている「良いやり方」だった。これによって、処理の流れと依存の方向性が逆転する = 依存性逆転を実現できる。
結果として、「不要不急の変更に(内部構造まで)振り回されることがない」、抽象度を高めた状態になれる。
多くの人と関わったり背負う責務の幅が広くなるほど、被依存が生じる = 安定度が高くなる。・・・「安定度が高くなる」と言うが、要するに「安定していなければ困るという度合いが高まる」、"不安定" "多動的"であってくれるなよという祈りが捧げられる。安定度が高いなら抽象度を同じくらいにまで高めなければならない。抽象度を高めるには、「意味のある」「明確な」Interfaceの設置だ。それが正に外部との接触面となり、他人とのやり取りの「出入り口」となる。
組織と個人の間では、責任と期待によってメッセージングされるものだと思っている。組織は人に責任を与えることで語りかけ、人は組織に期待を持って語りかける。「対組織とのやりとり」はそのまま「対・組織にいる誰か他の個人とのやりとり」と置き換えることも出来る。
往々にして、自分の属する組織≒環境に対しては「こうあって欲しい」という期待を抱くものだ。そして、その期待が満たされて嬉しかったり、不足があれば「裏切られた！！」とすら感じたりする。・・・これは、ひじょ〜〜に不安定である。
全てが上手くいけばいいのだが、「裏切られるかも」というリスクがある以上は、これをどうにか避けるための戦略が必要になると考えている。そうすることで、自身の存在を安定させられる。
ここで、掲題の通り「では、俺が依存するのではなくて、俺にどう依存するかはコチラの表明によって決定させてしまえばいい」と考える。これにより「使役先の振る舞いから自分の存在を保護できる」というものである。
依存性をどうコントロールするか？というと、インターフェイスの設置 = 「約束事」「取り決め」の公開だ。
「自分はこういう存在である、こういう事ができる、こういう風にしたいと思っているしその役割を果たさせてくれ」という「こう期待されたい」の期待値を、十分にexportしていく・・・・という取り組みは、「依存性の逆転」をもたらすことができないか？
環境による「裏切り」は、ひとたび起きてしまうと重大なダメージなると感じていて、自身の選択を嘆き続けるような日々をもたらす。
それを避けるために、なるべくコントローラブルにしていきたいものだ。
単純な話、積極的に「自分はこういう風にやっていくぞ、頼んだ！！」という合意をとっていくことで、他者との関わり方をしなやかにしていきたいと考える。
