なんどか再読していまだにクリーンアーキテクチャとかよくわからないが、冒頭のパラダイムや設計・コンポーネントの原則は繰り返し読んでいる
ひどいソースコードを見てげんなりしたときにどの原則に違反しているのかを考える。

パラダイム
・関数型プログラミング
・オブジェクト指向プログラミング
・構造化プログラミング

設計の5原則
・SRP：単一責任の原則「モジュールはただ一つのアクターに対して義務を負うべきである」
右足と左足を別のボートに置いて漕ぎ出せば水に落ちる、一つのモジュールは一つのボートに乗せなければならない
・OCP：オープンクローズドの原則「ソフトウェアの構成要素は拡張に対しては開いていて、修正に対して閉じていなければならない」
変更と拡張は既存の機能に対して影響を与えない修正が拡張
単一責任の原則を実践するために、何の仕事もしない、ｐジュールを作成し、それを拡張していくようなやり方でシステム開発をする
・LSP：リスコフの置換原則
インターフェイスと実装に関するソフトウェア設計の原則
きちんと定義されたインターフェイスに依存している
わかるようなわからないような、違反の例が分かりにくかった
・ISP：インターフェイス分離の原則
そのまんまだな、インターフェイスは具象を持たない名前だけ保持しているクラス
・DIP：依存関係逆転の原則
ソースコードの依存関係が具象ではなく、抽象だけを参照しているもの。それが最も柔軟なシステムである。
抽象と呼んでいるものは名前のことだな
関数名であれ、クラス名であれ、フィールド名であれ

コンポーネント凝集性の3原則
・REP:再利用・リリース等価の原則：再利用の単位とリリースの単位は等価になる
・CCP:閉鎖性共通の原則（SRP）：同じ理由、同じタイミングで変更されるクラスをコンポーネントにまとめること。変更の理由やタイミングが異なるクラスは、別のコンポーネントに分けること。
・CRP:全再利用の原則（ISP）：コンポーネントのユーザーに対して、実際には使わないものへの依存を強要してはいけない。
言い換えると不要なものに依存しないこと

REP：再利用性のためのグループ化←→再利用性の低下
CCP：保守性のためのグループ化←→変更すべきコンポーネントの増加
CRP：不要なリリース作業を減らすための分割←→不要なリリース作用の増加

REPとCCP⇒コンポーネントを大きくする
CRP⇒コンポーネントを小さくする

ブレークスルー：DevOpsの1日10回のリリース、1日170回の本番リリース

コンポーネントの結合の3原則
・ADP:非循環依存関係の原則
→コンポーネントの依存グラフに循環依存があってはならない
コンポーネント図に起こした時の話なのかな。
コンポーネントの構造をトップダウンで設計するのは不可能だということだ。

・SDP:安定依存の原則
安定度の高い方向に依存すること
安定度とは変更の頻度とは関係ないということだ
うーんよくわかってないな。

・SAP:安定度・抽象度透過の原則
コンポーネントの抽象度はその安定度と同程度でなければいけない。
抽象度が高くなる方向に依存するべきということになる。

アーキテクチャのポイント
フレームワーク非依存・テスト可能・UI非依存・DB非依存・外部エージェント非依存