CleanArch
とにかく一枚に書き出して、後でタグを使って構造化していく予定
まえがき、序文
何かを難しく伝えようとしています
時代が移り変わっても、ソフトウェアの構成要素が普遍的で変わらないので、それを組み立てるルール自体も変わらない。
そのルールを言語化していく
第1部 イントロダクション
第1章 設計とアーキテクチャ
設計とアーキテクチャには何も違いはない。
要は上位の構造と下位の詳細は全体の設計の同じ構成要素になるので区別することはできない。
あとは悲しい話が色々載っています。
第二章 2つの価値のお話
すべてのソフトウエアシステムはステークホルダーに2つの異なる価値を提供する
振る舞い
マシンがステークホルダの目的を達成できるようにコードを書く、振る舞いを与えるためにプログラマは雇用されている
それが仕事だと思われがち
構造
振る舞いを簡単に変更できなければならない、それが「ソフト」ウェアの価値
どちらが大事かというと、動作するが変更できないプログラムだと要件が変更されると機能しなくなり修正できず詰む。逆であれば、修正することで目的を達成できる。
この重要性ををビジネスマネージャーは評価できないジレンマがある。そのためソフトウェア開発者はアーキテクチャの重要性を強く主張する責任がある。戦え
第2部 構成要素から始めよ: プログラミングパラダイム
第3章 パラダイムの概要
ここから紹介するプログラミングパラダイムは、プログラマから能力を削除し規律を課している。何をすべきでないかを伝えている。
第4章 構造化プログラミング
gotoダメ
構造化プログラミングによってモジュールを証明可能な単位に再帰的に分割することを可能にした
アーキテクチャレベルにおいては機能分割がベストプラクティス
第5章 オブジェクト指向プログラミング
(急にボブおじさんがイライラし始める)
カプセル化
昔はできてたのに今はできないという謎の怒りをぶつけられる
継承
これは昔もできていたが今のほうが便利である
ポリモーフィズム
昔も関数へのポインタを応用して実現していたが、若干の危険がありそれを回避する規約を覚えておく必要があった。
OO言語によってこの規約を排除できている
依存関係逆転、これはパワーだ!
つまりUIやデータベースなどをビジネスルールのプラグインにできる
これにより独立デプロイ可能性がうまれる
ソフトウェアアーキテクトにおいてOOとはポリモーフィズムを使ってシステムにある全てのソースコードの依存関係を絶対的に制御する能力、という答えになる
第6章 関数型プログラミング
競合状態/デッドロックなど様々な問題の原因に可変変数がある
不変コンポーネントにできるだけ多くの処理を押し込み、可変コンポーネントからコードを削減していく
代入ダメ
第3部 設計の原則
いきなりSOLIDのウケる画像から始まる
第7章 SRP: 単一責任の原則
第8章 OCP: オープン・クローズドの原則
第9章 LSP: リスコフの置換原則
第10章 ISP" インターフェイス分離の原則
第11章 DIP: 依存関係逆転の原則
第12章 コンポーネント
第13章 コンポーネントの凝集性
第14章 コンポーネントの結合
第5部 アーキテクチャ
第15章 アーキテクチャとは?
第16章 独立性
第17章 バウンダリー: 境界線を引く
第18章 境界の解剖学
第19章 方針とレベル
第20章 ビジネスルール
第21章 叫ぶアーキテクチャ
第22章 クリーンアーキテクチャ
第23章 プレゼンターとHumble Object
第24章 部分的な境界
第25章 レイヤーと境界
第26章 メインコンポーネント
第27章 サービス:あらゆる存在
第28章 テスト境界
第29章 クリーン組み込みアーキテクチャ
第6部 詳細
第30章 データベースは詳細
第31章 ウェブは詳細
第32章 フレームワークは詳細
第33章 事例:動画販売サイト
第34章 書き残したこと
第7部 付録