S型のオブジェクトo1の各々に対する、T型のオブジェクトo2が存在し、Tを使って定義されたプログラムPに対してo2の代わりにo1を使ってもPの振る舞いが変わらない場合、SはTの派生型であるといえる
Pに対してo1とo2のの振る舞いに一貫性を持たせる。オブジェクト指向でいうところの、継承とポリモーフィズムの話。

ISP:インターフェイス分離の原則

クライアントは使用しないメソッドに対して依存すべきではない
使用していないメソッドに依存していると、そのメソッドの変更にともなって、クライアントも修正がひつようになるため、そのようなメソッドは分離するべき。

DIP:依存性逆転の法則

上位レベルのモジュールは下位レベルのモジュールに依存すべきでない
ここでいうレベルは、入出力からの距離のこと。ただ、全てのモジュールに対してこの原則を守り続けることは現実的でないため、レベルというよりも変化しにくい安定したモジュールに依存すべきということを意識することが重要。

クリーンアーキテクチャの概要

おなじみの図↓

依存性のルール

同心円は、円の中心に近づくほどレベルが上がっていく。円の外側はシステムの仕組み(詳細)、内側は方針(抽象)である。
ソースコードの依存性は、内側(上位レベルの方針)だけに向かっていなければいけない
内側は外側について、何も知らない。特に外側で宣言された名前は内側から使ってはいけない。

エンティティ

エンティティはビジネスルールを持ったシステムにおける最上位レベルのオブジェクトである。外部でUIやセキュリティの変化が起きたとしても、このオブジェクトが変更される可能性は低い。ビジネスルールとはビジネスマネーを生み出したり節約したりするルールや手続きのこと。例えば、銀行がローンにN％の利子をつけているとすると、それは銀行のお金を生む為のビジネスルールとなる。

ユースケース

ビジネスルールはエンティティほど純粋なものばかりではない。自動化されたシステムを定義・制限することによって、ビジネスマネーを生み出したりするルールもある。
このレイヤーにはアプリケーション固有のビジネスルールが含まれている。ユースケースはエンティティに入出力するデータの流れを調整し、ユースケースの目標を達成できるように、エンティティにルールを使用するように指示を出す。

インターフェイスアダプター

このレイヤーはユースケースやエンティティに便利なフォーマットから、DBやWebなどの外部に便利なフォーマットにデータを変換するアダプターである。また外部サービスなどから、エンティティが使用する形式に変換するアダプターも含まれる。

フレームワークとドライバ

フレームワークやツールで構成されている。例えば、DBやウェブフレームワークだど。このレイヤーにはシステムの詳細が詰まっており、変更しやすいオブジェクトでもある。

クリーンアーキテクチャの特性

フレームワーク非依存

アーキテクチャは、機能満載のソフトウェアライブラリに依存しない。フレームワークをツールとして使用できる。

テスト可能

ビジネスルールは、UI、DB、ウェブサーバー、その他の外部要素がなくてもテストできる。

UI非依存

UIは、システムの他の部分を変更することなく、簡単に変更できる。たとえば、ビジネスルールを変更することなく、ウェブUIをコンソールUIに置き換えることができる

データベース非依存

Oracle, SQL, Mongoなどに置き換えることができる。ビジネスルールはDBに束縛されていない。

外部エージェント非依存

ビジネスルールは、外界のインターフェイスについて何も知らない。

アーキテクトの心構え

クリーンアーキテクチャの概要は以上ですが、この本のアーキテクトやアーキテクチャとはなんぞやという解説が面白かったのでまとめておきます。

アーキテクトはプログラマである

アーキテクトはコードを書かず、より高いレベルの問題にフォーカスするものだ、というウソを信じてはダメだ。アーキテクトは最高のプログラマであり、継続してプログラミングの仕事を受けながら、生産性を最大化する設計にチームを導ていく。ほかのプログラマほどコードを書かないかもしれないが、自分で課題を経験していなければ、他のプログラマのために適切な仕事をすることなどできない。

優れたアーキテクトはソフトウェアに`選択肢`を残す

システムには「方針(抽象)」と「詳細（具象）」の二つの要素に分割できる。
「方針」には、ビジネスルールや手順など、システムの本当の価値がある。詳細にはIOデバイス、データベース、ウェブシステム、サーバー、フレームワークなどが含まれる。
ここでいう選択肢とは、システムにおいて重要ではない詳細のことである。アーキテクトの目的は、方針とは無関係に詳細を決めながら、方針をシステムの最も重要な要素と認識するシステムの形状を作ることである。こうすることで、詳細の決定を延期や保留することができる。

あなたのアーキテクチャは叫んでいるか？

優れたアーキテクチャを備えたショッピングカートのアプリケーションは、ショッピングカートのアプリケーションのように見える。　適切な設計を行えば、システムのユースケースを容易に理解することができ、そのシステムがどのようなものなのかが見えるようになる。
建物の設計図を想像してみよう。図書館の設計図を見ると、そこには正面玄関、受付、読書エリア、本の収納スペースある。これはアーキテクチャが「図書館」と叫んでいるのである。
ではあなたのアーキテクチャはなんと叫んでいるか？最上位レベルのディレクトリ構造と最上位レベルのソースファイルは、そのアプリケーションについて叫んでいるか？
ソフトウェアアーキテクチャはシステムのユースケースを支える構造であり、アーキテクチャはユースケースについて叫ぶべきである。

おわりに

本が届いたときは、めっちゃ分厚くて読むのしんどいなぁと思いましたが、和訳もわかりやすく、テーマごとに細かくセクションを切って解説されているので意外にサクッと読めました。

本を読んでみて、正直腑に落ちない点はいくつかあります。
例えば、開発着手時にDBやフレームワークの選定をしないことがあるのか。著者の考えからすると、フレームワークから開発を着手した時点で、「方針」が「詳細」に依存することになりアウトです。
ただ、ソフトウェアの本当の価値とは「方針」の中にあり、「詳細」は重要ではない、という主張に関しての筆者の経験からくる解説は十分に説得力のあるものでした。
ソフトウェアアーキテクチャの勉強をする上では非常に参考になる一冊だったと思います。

はじめに

結論

SOLID原則

SRP:単一責任の原則

OCP：オープン・クローズドの原則

LSP:リスコフの置換原則