はじめに

内容は非常に難解で、すべてを完全に理解するにはさらなる学習が必要だと感じています。そのため、1年後に再読しようと思います。

とはいえ、本書から多くの学びを得ることができたので、特に自分なりに解釈し理解できた部分をここにまとめます。

なお、ここでの記述は個人的な解釈を多分に含んでおり、誤解や不正確な部分が含まれる可能性があります。

学び

優れたアーキテクチャの目的は、開発チームが重要な事項に集中し付加価値を継続的に生み出すことができるようにすることと理解しました。
書籍の中でもメジャーリリースを経るたびに、生産性が下がっているグラフがありました。

私のPJの先輩エンジニアもシニアが書いても、ジュニアが書いてもコードは全て負債であると言っていたことを思い出しました。

クリーンアーキテクチャやその他原則は、コードが増えていく状況下で生産性の低下を緩やかにするため重要だと理解しました。

Clean Architecture　達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ) (Japanese Edition) (p. 37). 株式会社ドワンゴ. Kindle Edition.

普段の開発にすぐすぐ組み込むことは難しいが、下記にまとめる項目は頭に置くことで日々のコーディングがより良いものになると思いました。

組み込むことが難しいというか、曖昧な知識のまま組み込むべきではないですね。
当たり前ですが、組み込むメリット、デメリット整理やチーム内での共通知識が必須だと思いました。

ソフトウェアは「振る舞い」と「構造」を価値提供する

「振る舞い」要件を満たすこの方が重要視した結果、変更のコストがメリットを上回り、変更が事実上不可能なシステムは実際に存在する

SOLIDの目的は、変更に強く、理解しやすく、コンポーネントの基盤として多くのシステムで利用できることである

モジュールが一つのことだけをするべきと誤解されることが多いが、本当はアクターの異なるコードは分割すべきであるということ。

例として、Employeeクラスが3つのメソッドを持ち、それぞれが別々のアクターに対する責務を負う場合は分割すべき

ソフトウェアは拡張に対しては開いていて、修正に対して閉じているべきということ
言い換えると、ソフトウェアの振る舞いは、既存の成果物を変更せず拡張できるようにすべきである

インターフェイス経由で別のクラスを呼んだ場合に、実行するロジックが複数あったとして（派生型）入れ替えても問題がない状況ということ

インターフェイスを分離することで、不要なソースコードに依存しないようにすること

変化しやすい具象クラスを継承しない、抽象だけを参照するのが最も柔軟であるということ
直接参照するのではなく、安定した抽象インターフェイスに依存させるべき

円の内側は外側について何も知らない、内側のコード（例えばエンティティ）が外側のコード（例えばユースケース）を利用してはいけない

レイヤーに分けて、依存のルールを守ることでテスト容易性にもつながる

Clean Architecture　達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ) (Japanese Edition) (p. 250). 株式会社ドワンゴ. Kindle Edition.

最重要ビジネスルールのことを指す
システムが存在しなくても存在する、ビジネスにとって欠かせないもののこと
企業のビジネスルール

例えば、銀行で言うところの利子N%に当たる

エンティティをいつ、どのように呼び出すかなどを規定したルールのこと
アプリケーション固有のビジネスルール

例えば、銀行がお客さんの情報を受け取り、与信判定の基準を超えているか判定したのちに見積もりを渡す一連の流れに当たる

ユースケースやエンティティを、データベースやビューに便利なフォーマットへ変換する層のこと
MVCアーキテクチャなどがここに当たる

ウェブやデータベースのこと

ソフトウェアの世界では重複は悪だとされ、好まれない
しかし本物の重複と、偽物（偶然）の重複が存在するため注意が必要

画面が似ているからといって反射的に共通化することで、将来的に辛い分離作業がやってくる