「Clean Architecture 達人に学ぶソフトウェアの構造と設計」を読んだのでそのまとめです。
第III部 設計の原則
よくできたソフトウェアシステムはクリーンなコードを書くことから始まる
SOLID原則の目的は、変更に強く、理解しやすく、コンポーネントの基盤として広く利用できることである
第7章 SRP：単一責任の原則
「ひとつの関数はひとつのことだけ行うべき」は誤解である
モジュール（ソースファイル）はたったひとつのアクターに対して責務を負うべきである
SRPはコードレベルの原則だが、同じような原則はコンポーネントレベル（CCP）やアーキテクチャレベル（境界を作るための「変更の軸」）として登場する
第8章 OCP：オープン・クローズドの原則
ソフトウェアの構成要素は拡張に対して開き、修正に対して閉じていなければならない
ソフトウェアの振る舞いは、既存の成果物を変更せずに拡張できるようにすべきである
コンポーネントレベルではより重要になる
コンポーネントを分割して、依存関係を階層構造にし、上位レベルのコンポーネントが下位レベルのコンポーネントから影響を受けないようにする
第9章 LSP：リスコフの置換原則
交換可能なパーツとして構築するなら、個々のパーツが交換可能となるような契約に従わなければならない
これに違反すると特別なコードを埋め込み複雑で特別な仕組みだらけになる
アーキテクチャレベルにも適用すべき原則である
第10章 ISP：インターフェイス分離の原則
使っていないものへの依存は回避すべきである
使っていないモジュールに依存した場合、本来不要なはずのコンパイルやデプロイにも影響を与える
第11章 DIP：依存関係逆転の原則
上位レベルの方針のコードは下位レベルの詳細のコードに依存すべきではなく、逆に詳細側が方針に依存すべきである
ソースコードの依存関係が抽象だけを参照しているもの、それが最も柔軟なシステム
インターフェイスは実装よりも変化しにくい安定した抽象である
具象オブジェクトはどこかで生成しなければならず、その際にAbstract Factoryパターンを使って依存性を管理する
抽象コンポーネントには上位レベルのビジネスルールが含まれる
具象コンポーネントにはビジネスルールが操作する実装の詳細が含まれる
