依存とは
依存 (dependency): 対象の存在を前提とし、対象の変更に影響を受ける状態. couplingとも
依存は悪いものなのか
依存対象を必要とする
対象の存在を前提としている
-> 対象が存在していない（？）とそこへ依存した部分が構築できない
e.g. 利用するデータ保存手法が未定->そこに依存したコードが書けない
変更
対象の変更に影響を受ける
-> 対象の変更が自分の修正を引き起こしうる
-> 依存"されている"場合、変更が他箇所へ影響を与えうる
依存を無くすことは可能か
他要素との相互作用（呼び出し、変更など）を除去すれば可能だが、それは他要素を削除することと同義
無くせないならポイントは
何に、どの方向で、依存するか
自分（のようなもの）に依存する分には構築が始めやすいし、他者に振り回されずに済む
依存するinterfaceを自分で定義すればある程度コントロールできる
依存するinterfaceを自分で定義したら楽なのはそれはそう.
使われる側は自身がimplicit interfaceなので楽.
中心的関心領域が様々なEntityへ"依存している"ことの弊害:
依存対象が存在しないと依存部分の設計ができない
中心的関心領域が肝だから、そこだけに注目してまず設計したい
-> 中心的関心領域側でinterfaceを切り、自ら設定したinterfaceへ依存する
# Interface: 明示され、変更頻度を低くすることが合意された、構造体・命令の形式
依存の良い扱い方
中心的関心領域が自らinterfaceを定義し、それに依存する
ヘキサゴナル・オニオン・クリーン
人間は不完全なので、実装が存在する領域を起点としてそこに依存したアーキテクチャを作ってしまう
e.g. RDBMSがあるので、そのAPIを起点にデータ保存を抽象化し、その後データ保存関数へ入れるデータをモデリングしていく
抽象がどうしてもRDBMSに引っ張られてしまう
DBアクセス速度を売りとした超高速アプリ、みたいな場合、DBアクセスは中心的関心領域なのでは？
DBは主役級、DBはinterfaceを切る側に立つのは合理的
依存関係
