勉強まとめ

1. Clean
Architecture
第Ⅳ部
コンポーネントの原則

2. 前回まとめ
- 単一責任の原則
- （SRP：Single Responsibility Principle）
- 変更する理由がたった一つだけになるように
- オープン・クローズドの原則
- （OCP：Open-Closed Principle）
- 拡張に対しては開いていて、修正に対しては閉じていなければならない
- リスコフの置換原則
- （LSP：Liskov Substitution Principle）
- 個々のパーツが交換可能となるような契約に従わなければいけない
- インターフェイス分離の原則
- （ISP：Interface Segregation Principle）
- 使っていないものへの依存を避けるべき
- 依存関係逆転の原則
- （DIP：Dependency Inversion Principle）
- 上位レベルの方針の実装コードは、下位レベルの詳細の実装コードに依存すべきではなく、逆に詳
細側が方針に依存すべきである

3. - コンポーネント
- コンポーネントの凝縮性
- コンポーネントの結合
第Ⅳ部：コンポーネントの原則

4. 第1章：コンポーネント
- コンポーネントとはデプロイ単位のことである
- システムの一部としてデプロイできる最小単位
- 優秀なコンポーネントは常に個別にデプロイができる状態を保っている
- つまり個別に開発を進められる

5. 第1章：コンポーネント
コンポーネントの歴史（ざっくり）
- 大昔はPGをメモリ上のどの場所にどの
ように配置するか決めていた
- PGは再配置可能ではなかった
- 現代では、コマンドを叩くだけで再利用
可能なライブラリをプラグインできる

6. 第2章：コンポーネントの凝縮性
- どのクラスをどのコンポーネントに含めるのか？
- 再利用・リリース等価の原則（ REP）
- 閉鎖性共通の原則（ CCP）
- 全再利用の原則（ CRP）

7. 第2章：コンポーネントの凝縮性
再利用・リリース等価の原則（REP）
- 再利用とリリースの単位は等価になる

8. 第2章：コンポーネントの凝縮性
閉鎖性共通の原則（CCP）
- 単一責任の原則をコンポーネントで言い換えただけ
- コンポーネントを変更する理由が複数あるべきではない
- 変更のタイミングがいつも一緒になるのであれば同じコンポーネントに属すようにする

9. 第2章：コンポーネントの凝縮性
全再利用の原則（CRP）
- コンポーネントのユーザーに対して、実際に使わないものへの依存を強要してはならない
- どのクラスを同じコンポーネントに「まとめるべきではないか」
- 密結合していないクラスを同じコンポーネントにまとめるべきではない
- インターフェイス分離の原則との共通点
- 不要なものには依存しないこと

10. 第2章：コンポーネントの凝縮性
コンポーネントの凝縮性のテンション図

11. 第3章：コンポーネントの結合
- 非循環依存関係の原則（
ADP）
- コンポーネントの依存グラフに循環依存があってはいけない
- Eslintの import/no-cycle によって検知できる
- 安定依存の原則（SDP）
- 安定度の高い方向に依存すること
- 安定度・抽象度等価の原則（
SAP）
- コンポーネントの抽象度は、その安定度と同程度でなければいけない

12. 第3章：コンポーネントの結合
非循環依存関係の原則（ADP）
- Eslintの import/no-cycleで検知できる
- お互いに依存していると処理がループしてしまう
- 循環依存の解消
1. 依存関係逆転の原則を適用する
2. 両方が依存する新しいコンポーネントを作る

13. 第3章：コンポーネントの結合
安定依存の原則（SDP）
- 安定度の高い方向に依存すること
- 安定度：多くのコンポーネントから「依存されている」変更する理由を増やす
- 独立コンポーネント：どこからも「依存されていない」コンポーネント

14. 第3章：コンポーネントの結合
安定度の指標
- ファン・イン：依存入力数。コンポーネント内のクラスに依存している外部コンポーネントの数を
表す
- ファン・アウト：依存出力数。コンポーネント内にあるクラスに依存しているクラスの数を表す
- I(Instability)：不安定さ。I = ファン・アウト÷ (ファン・イン+ ファン・アウト)
- この指標は、ゼロ以上 1以下の値になる
- I = 0 が最も安定しているコンポーネントを表し、 I = 1 が最も不安定なコンポーネントを表す

15. 第3章：コンポーネントの結合
安定度・抽象度等価の原則（SAP）
- コンポーネントの抽象度は、その安定度と同等でなければならない
- 安定度の高いコンポーネントは抽象度も高くあるべき
- 抽象度が高くなる方向に依存すべき
- 上位レベルのアーキテクチャや方針を示すものは頻繁に変更すべきではないので、安定度の
高いコンポーネントに配置しなければならない

16. 第3章：コンポーネントの結合
抽象度の計測
- Nc: コンポーネント内のクラスの総数
- Na: コンポーネント内の抽象クラスとインターフェイスの総数
- A: 抽象度。A = Na ÷ Nc
- Aは0から1までの値をとる。この値が
0であれば、そのコンポーネント
に抽象クラスやインターフェイスが一切含まれないことを表す。この値
が1であれば、そのコンポーネントには抽象クラスやインターフェイスし
か含まれないことを表す。
- (I/安定度、A抽象度)の数値が入る
- 除外すべき範囲(苦痛ゾーン/無駄ゾーン)(図参照)
- つまり(0、1)か(1、0)にすべき
- 苦痛ゾーンにはデータベーススキーマや具象ユーティリティライブラリ
が該当する
- D(Distance): D = |A + I - 1| 0以上1以下の値となる。値が 0の場合は主
系列にある。値が 1の場合は主系列から最もかけ離れた状態。

17. 第Ⅳ部：まとめ
- コンポーネント
- コンポーネントとはデプロイ単位のことである
- 優秀なコンポーネントは常に個別にデプロイができる状態を保っている
- コンポーネントの凝縮性
- 再利用・リリース等価の原則（ REP）
- 閉鎖性共通の原則（ CCP）
- 全再利用の原則（ CRP）
- コンポーネントの結合
- 非循環依存関係の原則（ ADP）
- 安定依存の原則（ SDP）
- 安定度・抽象度等価の原則（ SAP）