Riin's Workspace: 読了：Clean Architecture 達人に学ぶソフトウェアの構造と設計

エンジニアなら読むべき本○冊とかでよく目にするので、
とりあえず買っといて積んでた奴を崩しました。

アーキテクチャのルールはどれも同じである! どんな種類のシステムでもソフトウェアアーキテクチャのルールは同じ。ソフトウェアアーキテクチャのルールとは、プログラムの構成要素をどのように組み立てるかのルールである。時代を超越した不変のルールたちを紹介する。

読み終わってから腑に落ちまでちょっと時間のかかった本

### 目次
- まえがき
- 序文
  - 謝辞
  - 著者について

- 第I部　イントロダクション
  - 第1章　設計とアーキテクチャ
    - 目的は？
    - ケーススタディ
    - まとめ
  - 第2章　2つの価値のお話
    - 振る舞い
    - アーキテクチャ
    - 大きな価値
    - アイゼンハワーのマトリックス
    - アーキテクチャの戦い
- 第II部　構成要素から始めよ：プログラミングパラダイム
  - 第3章　パラダイムの概要
    - 構造化プログラミング
    - オブジェクト指向プログラミング
    - 関数型プログラミング
    - 考えるべきこと
    - まとめ
  - 第4章　構造化プログラミング
    - 証明
    - 有害宣言
    - 機能分割
    - 正式に証明できない
    - 救済のための科学
    - テスト
    - まとめ
  - 第5章　オブジェクト指向プログラミング
    - カプセル化とは？
    - 継承とは？
    - ポリモーフィズムとは？
    - まとめ
  - 第6章　関数型プログラミング
    - 整数の二乗
    - 不変性とアーキテクチャ
    - 可変性の分離
    - イベントソーシング
    - まとめ
- 第III部　設計の原則
  - 第7章　SRP：単一責任の原則
    - 症例1：想定外の重複
    - 症例2：マージ
    - 解決策
    - まとめ
  - 第8章　OCP：オープン・クローズドの原則
    - 思考実験
    - 方向の制御
    - 情報隠蔽
    - まとめ
  - 第9章　LSP：リスコフの置換原則
    - 継承の使い方の指針
    - 正方形・長方形問題
    - リスコフの置換原則（LSP）とアーキテクチャ
    - リスコフの置換原則（LSP）違反の例
    - まとめ
  - 第10章　ISP：インターフェイス分離の原則
    - インターフェイス分離の原則（ISP）と言語との関係
    - インターフェイス分離の原則（ISP）とアーキテクチャとの関係
    - まとめ
  - 第11章　DIP：依存関係逆転の原則
    - 安定した抽象
    - Factory
    - 具象コンポーネント
    - まとめ
- 第IV部　コンポーネントの原則
  - 第12章　コンポーネント
    - コンポーネントの簡単な歴史
    - リロケータビリティ（再配置可能性）
    - リンカ
    - まとめ
  - 第13章　コンポーネントの凝集性
    - 再利用・リリース等価の原則（REP）
    - 閉鎖性共通の原則（CCP）
    - 全再利用の原則（CRP）
    - コンポーネントの凝集性のテンション図
    - まとめ
  - 第14章　コンポーネントの結合
    - 非循環依存関係の原則（ADP）
    - トップダウンの設計
    - 安定依存の原則（SDP）
    - 安定度・抽象度等価の原則（SAP）
    - まとめ
- 第V部　アーキテクチャ
  - 第15章　アーキテクチャとは？
    - 開発
    - デプロイ
    - 運用
    - 保守
    - 選択肢を残しておく
    - デバイス非依存
    - ダイレクトメール
    - 物理アドレス
    - まとめ
  - 第16章　独立性
    - ユースケース
    - 運用
    - 開発
    - デプロイ
    - 選択肢を残しておく
    - レイヤーの切り離し
    - ユースケースの切り離し
    - 切り離し方式
    - 独立した開発が可能
    - 独立デプロイ可能性
    - 重複
    - 切り離し方式（再び）
    - まとめ
  - 第17章　バウンダリー：境界線を引く
    - 結合の悲しい物語
    - FitNesse
    - あなたの境界線は何か？　いつ境界線を引くのか？
    - 入力と出力はどうする？
    - プラグインアーキテクチャ
    - プラグインの戦い
    - まとめ
  - 第18章　境界の解剖学
    - 境界を越える
    - 恐怖のモノリス
    - デプロイコンポーネント
    - スレッド
    - ローカルプロセス
    - サービス
    - まとめ
  - 第19章　方針とレベル
    - レベル
    - まとめ
  - 第20章　ビジネスルール
    - エンティティ
    - ユースケース
    - リクエストとレスポンスのモデル
    - まとめ
  - 第21章　叫ぶアーキテクチャ
    - アーキテクチャのテーマ
    - アーキテクチャの目的
    - だが、ウェブはどうか？
    - フレームワークはツールであり、生き方ではない
    - テスト可能なアーキテクチャ
    - まとめ
  - 第22章　クリーンアーキテクチャ
    - 依存性のルール
    - 典型的なシナリオ
    - まとめ
  - 第23章　プレゼンターとHumble Object
    - Humble Objectパターン
    - プレゼンターとビュー
    - テストとアーキテクチャ
    - データベースゲートウェイ
    - データマッパー
    - サービスリスナー
    - まとめ
  - 第24章　部分的な境界
    - 最後のステップを省略する
    - 片方だけの境界
    - Facade
    - まとめ
  - 第25章　レイヤーと境界
    - Hunt the Wumpus
    - クリーンアーキテクチャ？
    - 流れを横切る
    - 流れを分割する
    - まとめ
  - 第26章　メインコンポーネント
    - 究極的な詳細
    - まとめ
  - 第27章　サービス：あらゆる存在
    - サービスアーキテクチャ？
    - サービスのメリット？
    - 子猫の問題
    - 救世主のオブジェクト
    - コンポーネントベースのサービス
    - 横断的関心事
    - まとめ
  - 第28章　テスト境界
    - システムコンポーネントとしてのテスト
    - テスト容易性のための設計
    - テストAPI
    - まとめ
  - 第29章　クリーン組込みアーキテクチャ
    - 適性テスト
    - ターゲットハードウェアのボトルネック
    - まとめ
- 第VI部　詳細
  - 第30章　データベースは詳細
    - リレーショナルデータベース
    - なぜデータベースシステムが普及しているのか？
    - もしもディスクがなかったら？
    - 詳細
    - だけど、パフォーマンスはどうなの？
    - 小話
    - まとめ
  - 第31章　ウェブは詳細
    - 止まらない振り子
    - 結論
    - まとめ
  - 第32章　フレームワークは詳細
    - フレームワークの作者たち
    - 一方的な結婚
    - リスク
    - 解決策
    - 今あなたたちを夫婦として宣言する
    - まとめ
  - 第33章　事例：動画販売サイト
    - プロダクト
    - ユースケース分析
    - コンポーネントアーキテクチャ
    - 依存性管理
    - まとめ
  - 第34章　書き残したこと
    - レイヤーによるパッケージング
    - 機能によるパッケージング
    - ポートとアダプター
    - コンポーネントによるパッケージング
    - 悪魔は実装の詳細に宿る
    - 組織化かカプセル化か
    - そのほかの分割方法
    - まとめ：言い残したこと
  - 第VII部　付録
    - 付録A　アーキテクチャ考古学
    - 組合の会計システム
    - レーザーカット
    - アルミダイキャストの監視
    - 4-Tel
    - サービスエリアコンピュータ
    - C言語
    - BOSS
    - pCCU
    - DLU/DRU
    - VRS
    - 電子受付
    - 転送システムの作成
    - 明確なコミュニケーション
    - ROSE
    - アーキテクト登録試験
    - まとめ
- あとがき
- 訳者あとがき

### 感想
目次長ッ

<br>
読んでる最中、ずっと「良いのはわかるけどオーバーエンジニアリングでは？」  
 みたいな感覚がずっと脳裏にチラついていて読むのちょっとしんどかったです。

多分これは今までスクリプト言語しか触ったことがないからと、  
個人で触るものには本当にオーバーエンジニアリングだし、  
必要なぐらいのコード量のプロダクトはそうなってなくて全部手遅れだったからかなあ。

ちゃんと抽象化して依存関係の方向を整えて……ってやってあるプロダクトに触れてから読み直すと  
 今度はすっと入ってきそうだなーとか思ってます。

<br>
何にせよ、なかなか入ってこない本ではあったけど、  
一回読んだことで自分の中にとっかかりがたくさんできたと 思うので  
一度読んだことはいい経験だったかなと。

そんな一冊でした。

2019年1月14日月曜日

読了：Clean Architecture 達人に学ぶソフトウェアの構造と設計

0 件のコメント:

コメントを投稿