Clean Architectureのメモ
#読書メモ
#ソフトウェアアーキテクチャ
#アーキテクチャ
SOLID原則について、コンポーネント、ソフトウェアアーキテクチャレベルで見た場合に、どう考えるか？みたいなこと
結論的には、コンポーネント（モジュールとか、ソフトウェアアーキテクチャレベル）の以下についての話
凝集度
結合度
依存関係の方向の制御
依存関係の方向
依存関係が循環参照になってはいけない
有向非循環グラフになってないとだめ
DIPで依存の方向性を制御する
それこそがオブジェクト指向だと言っている
安定度が高いコンポーネントに低いコンポーネントは依存すべき
言い換えると抽象度が高いコンポーネントに、抽象度が低いコンポーネントは依存すべき
例
抽象度が高いビジネスコンポーネントに、具体的な画面やDBなどは依存すべき
ビジネスコンポーネントに、画面やDBに関するコードは書くべきでは無い
そうなるとあの同心円の図になるようだ
中心に向かって依存していく
中心に向かって抽象度が上がる　
抽象度という言い方がピントは来ないが、書いてある事から読み解くとそうだね、ってところ
ただ、抽象度が高いコンポーネントも変更は出来るようにしたいから、依存関係を逆転させるべく、インターフェースと抽象クラスで制御しよう、となる
抽象度という考え方
Nc
コンポーネント内のクラスの総数。
Na
コンポーネント内の抽象クラスとインターフェイスの総数。
A：抽象度
A = Na ÷ Nc
安定度という考え方
安定しているとは、変更がしづらいということ
安定という言葉で良いのか微妙だが、とりあえずは多数のコンポーネントから参照されていると、変更するのが大変なので、安定度が高いという定義
計算方法
ファン・イン
コンポーネント内のクラスを利用している外部のコンポーネントの数
ファン・アウト
コンポーネント内にある外部のコンポーネントを利用しているクラスの数
I （Instability）：不安定さ
ファン・アウト÷(ファン・イン + ファン・アウト)
０〜１の間
安定度の高いコンポーネント
システムの上位レベルの方針
よく分からないがビジネスを表している、価値を生むものということかな？
すぐに変更が出来ない
外部のコンポーネントから複数参照されている
変更が出来ないと困る
抽象度を高くする、つまり抽象クラス
安定度の低いコンポーネント
すぐに変更が出来る
詳細なもの
画面とかDBとか、具体的なものを言っているようだ
SOLID原則
SRP（単一責任の原則）
凝集度を高めましょう
アクターレベルで、変更理由が１つになるように
OCP（オープン・クローズドの原則）
依存関係を制御して、可能な限り情報を隠蔽し、インターフェースによるプログラミングで、柔軟に拡張できるようにしておきましょう
DIP（依存関係逆転の法則）で、依存関係を制御
LSP（リスコフの置換原則）
結合度を低くしましょう
インターフェースによるプログラミングで、結合度を低くして、置換可能なようにしておきましょう
ISP（インターフェース分離の原則）
DIP（依存関係逆転の原則）