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

今後の自分のキャリアを、クラウドネイティブを主にしたアーキテクト！ と決めた中で勉強本を探して出てきた１冊。 アーキテクトをとしてシステムを設計するための基本原則がまとめられており、評判どおり大満足の内容。 自分の備忘のためにも投稿、主観もかなり入っています。

1. 書籍の紹介

Clean Architecture　達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ)

著者
ロバート・C. マーチン(通称：アンクルボブ)
→アメリカのソフトウェアエンジニア、cleancodrs.comの共同創始者、いくつかの設計原則の開発やアジャイル宣言の作者として有名

en.wikipedia.org

2. 書籍の要約

Ⅰ部　イントロ * ソフトウェアの２つの価値：振る舞い とアーキテクチャ
* アーキテクチャが崩れる可能性はたびたびある、四象限に分類し優先順位付 　→アイゼンパワーのマトリックス、下記順番で対応するのがよい 　　 1.重要緊急　２重要緊急ではない　３重要ではない緊急　４重要ではない緊急ではない

Ⅱ部　プログラミングパラダイム * 構造化プログラミング
　→go to 文を排除し、if/then/elseに：直接的な制御の移行に対する規律 * オブジェクト指向プログラミング
　→カプセル化、継承、ポリモーフィズム：間接的な制御の移行に対する規律 * 関数型プログラミング
　→代入の制約（参照渡しなど）：代入に対する規律
* それぞれのパラダイムはプログラムに規律を課している、それぞれ、機能・コンポーネントの分離・データ管理に対応。

Ⅲ部　設計原則 * SOLID原則 1. 単一責任の原則　SRP
　→クラスは単一の責任のみ保有するべき、クラスは責任の範囲で定義する 2. オープン・クローズドの原則　OCP
　→変更の影響は受けにくく、システムは拡張しやすい。クラスの関係に対する方向の向きや、クラスの持ち方について 3. リスコフの置換原則　LSP
　→継承の使い方の指針、RectangleとSquareの話 4. インターフェイス分離の原則　ISP
　→そのまま。分けましょう 5. 依存関係逆転の原則　DIP
　→OCPが成り立つように関係を定義する、抽象化の原則。プログラムの流れとクラスの関係が逆になるため、この名前
　　Abstract Factoryパターン

• コンポーネントの凝集性(Cohesion)
  ※凝集性：情報工学においてモジュール内のソースコードが特定の機能を提供すべく如何に協調しているかを表す度合いである。 　　　　IPAが実施する情報処理技術者試験では、強度という言葉が使われる。凝集度は順序尺度の一種であり、「凝集度が高い」とか「凝集度が低い」といった言い方で使われる。

• 再利用・リリース等価の原則（REP）

• 閉鎖性共通の原則（CCP） 　→同じ理由、タイミングで変更されるクラスをコンポーネントにまとめる、変更の理由やタイミングが異なるクラスは別コンポーネント
  　→SRPと類似

• 全再利用の原則（CRP） 　→コンポーネントのユーザーに対して、実際に使わないものへの依存を強要してはいけない（ISPを一般化したもの）

• コンポーネントの結合

• 非循環依存関係の原則（ADP）
  　→コンポーネントの依存グラフに循環依存があってはいけない
• 安定依存の原則（SDP）
  　→安定度の高い方向に依存させる
• 安定度・抽象度の原則（SAP）
  　→コンポーネントの抽象度は安定度と同程度でないといけない
  ※依存性管理の指標
• バンダリーを引く。ソフトウェアアーキテクチャとはバウンダリーを引く技芸
• クリーンアーキテクチャ
  　→フレームワーク非依存、テスト可能、UI非依存、データベース非依存、外部エージェント非依存
  　→１．ビジネスルール、２．アプリケーションのビジネスルール、３．インターフェイスアダプター、４．フレームワークとドライバー

クリーンアーキテクチャ(The Clean Architecture翻訳) | blog.tai2.net

3. 所感

原則の内容詳細は正直薄いが、アーキテクチャの全体感を捉える意味で良かった。ただ少し歴史を感じる。 あるべきはまさに示されている原則にしたがって実行するというのは理解できるが、Howが書かれていない。 これをどこまで咀嚼し実行できるか試されている気がします。