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

www.kadokawa.co.jp

本を読み始めた時の目的

本を読み始める時は目的を持ったほうが頭に入りやすい。

第1章 設計とアーキテクチャ

ソフトウェアアーキテクチャの目的は、求められるシステムを構築・保守するために必要な人材を最小限に抑えることである。

メタ的だが、第1章でアーキテクチャを適用する目的について語られているのがGoodだと思った。
なんとなくかっこいいから、なんとなく洗練されてるから等というフワフワな目的ではなく、人的リソースの最小化に焦点を当てている。

第2章 2つの価値のお話

すべてのソフトウェアシステムは、ステークホルダーに2つの異なる価値を提供する。それは「振る舞い」と「構造」だ。

2つ提供するはずが、どっちか疎かになっちゃうよね、という話。
受託開発だと振る舞いに目が行きがち(悪いことではないとは思う)だが、理想としては振る舞いを提供した上で構造も担保したい。

第7章 SRP: 単一責任の原則

モジュールはたったひとりのアクター(変更を望む人たち)に対して責務を負うべきである

複数の要因でソースコードの変更が同時期に行われることを避けるために、責務を分けたクラス設計を行う。

第8章 OCP: オープン・クローズドの原則

ソフトウェアの構成要素は拡張に対しては開いていて、修正に対して閉じていなければならない。

Swiftで言うとプロトコル切ってモジュール間でやりとりしようね、そうすると追加開発しやすくなるよ、という話。
例えば条件に応じてAPI通信を利用してデータをfetchするクラスと、アプリ内キャッシュを利用してデータを流用するクラスをそれぞれInputプロトコルなるものに準拠させておけば、他のルートでデータを取得するクラスが必要になった時に、そのプロトコルに準拠さえしておけば利用先(= 上位モジュール)でDIするだけで使えるよね、拡張に対して開いているね、という話。

第11章 DIP: 依存関係逆転の原則

ソースコードの依存関係が(具象)ではなく抽象だけを参照しているもの。それが、最も柔軟なシステムである。

今まで理解できなかったが、普段の開発で当たり前にやっていたことだと気づいた。

# ng
上位モジュール -> 下位モジュール

# ok
上位モジュール -> プロトコル <- 下位モジュール

Swiftで言うと上位も下位もお互いプロトコル使ってやりとりしようね、という話。

第17章 バウンダリー: 境界線を引く

ソフトウェアアーキテクチャとは、境界線を引く技芸である。(中略)。ソフトウェアの要素を分離し、お互いのことがわからないように制限するというものである。

なるほど。確かに良い設計というのは境界線をいかに引くか、がかなり大事だと思う。

第20章 ビジネスルール

ビジネスルールは出力先・利用先のことは知らなくていいよね、独立させようね、という話。
DDDをちょっと勉強してた時にも同じことを聞いた気がする。

第23章 プレゼンターとHumble Object

humble: 謙虚、控えめの意。

  • テストしにくい振る舞いとしやすい振る舞いを分離するパターン
  • GUIなどのViewはテストがしにくいが、ビジネスロジックなどを別のクラスか何かに書くことでユニットテストを書きやすくできる

ほとんどMVPのViewとPresenterの話に見受けられ、普段使っているアーキテクチャということで理解はOKそう。

第25章 レイヤーと境界

システムは「UI」「ビジネスルール」「データベース」という3つのコンポーネントで構成されていると考えるとわかりやすいだろう

図25-3 (P217) がかなりしっくりきた。

第26章 メインコンポーネント

すべてのシステムには、そのほかのコンポーネントを作成・調整・監督するコンポーネントが少なくとも1つ存在する。私はこのコンポーネントを Main と読んでいる。

  • Mainは究極的な詳細

第29章 クリーン組み込みアーキテクチャ

まとめ

  • この本から読書ログと称してブログを書くようにした、中だるみしにくくて継続して読めて良さげ
  • 後半難しそうで読む気がしなかった。少なくとももう1周はする
  • あまりこれといって収穫物がなかった(後半飛ばしたのでそこをちゃんと読めば解消するかもしれない)
  • 変更する時の理由が1つである責務を持ったクラスの切り方を普段から意識していれば殆ど本に書かれていることは理解できてそう

参考