読書ノート『Clean Architecture』総まとめ

6回に分けて書いていた読書ノートの総まとめである。

途中諸々の事情で積んでたりしたので読了まで３ヶ月以上要したが、ともあれ読了したので総まとめを書いておく。

本書で述べたいこと

『クリーンアーキテクチャ』といえば例の同心円状の図であるが、本書に於いて最も重要であるかとそうではない。

もちろんあれはコンポーネント・レイヤーを簡潔に示していてそれはそれで重要なのであるが、本書内でも別にレイヤー数は４つである必要がないと書かれているし、これは単なる実装されたアイデアの一つにすぎない。

真に重要なのはバックグラウンドにあるソフトウェア設計の原理原則であり、それを遵守すれば必然的に導出されてくるのがあの図である。

最も重要な原理原則に関してはⅡ部でしっかりと語られており、それ以降の部ではそれを具体的な粒度で詳解しているのが実情だ。

アーキテクチャはなぜ重要か？

冒頭Ⅰ部の内容であるが、これは原理原則と同様に重要な内容である。

クリーンアーキテクチャは単なる学術的関心の対象ではなく、ソフトウェア開発の現場で起きている実際の課題を解決し、経済的価値をもたらすものだからだ。（だから安心して経費で購入申請を上げるといい）

「綺麗なコード」に関しては、しばしばその必要性に関して議論が行われる。

不要論として筆頭に上がるのが「動けばいい」という理屈、つまり機能を提供していればいいという見方である。

だが実際にソフトウェアに期待されている要件とは、「動く」のではなく「動き続ける」ことなのだ。

実際には書き捨てのコードなども有るわけなので、作ろうとしているソフトウェアが『石橋』なのか『100均の割り箸』なのかはよく見定める必要がある。（つまりエンジニアリングをしているのかマニュファクチュアをしているのかという話である）

クリーンアーキテクチャはまさしくこのこの動き『続ける』という価値、すなわち保守性に大きく関わってくる。

そのソフトウェアが価値を提供し続けるかという話は即ち、BSの資産の部にどれだけ長く（そして省エネで）居座るかという話でも有る。

ここまで説明してアーキテクチャの重要性が伝わらないのであれば、その会社の将来をまず心配すべきだろう。
（尤も、ソフトウェアを納品して終わりというビジネスモデルであればその限りではないが・・・・）

ソフトウェア設計の原則とは？

まず前提として、コンポーネント間の関係を成立させるために３つのプログラミングパラダイムが必要になる。

『構造化プログラミング』により解くべき問題を分割統治可能にしてコンポーネントという単位を定義可能にし、『ポリモーフィズム』によりコンポーネント間の依存関係を制御し、『関数型プログラミング』を適用することでコンポーネントをステートレスにすることができる。

要するに大きなソフトウェアを小さい構造分割して、依存関係と状態管理を適切に行いなさいという話である。

ある程度複雑なソフトウェアなら、構造の中には構造が有って・・・と何段階のメタ構造になっているので、各粒度の構造に関して設計の指針が若干変わってくる。

なので小さい粒度から順に書いていってくれているのであるが、内容としては反復してる内容が多い。

結局のところ、無関係な修正の影響を受けないように分割単位を決定し、変更の影響を受けないように、不安定な要素から安定な要素に依存させるのだ。

アーキテクトの仕事とは？

ソフトウェア設計の原則を最上位構造（＝アーキテクチャ）に対して当てはめるに際して最も注意すべきは、アーキテクチャは最上位の構造であるから最も大枠の指針を示すものであるということだ。

つまり長期に渡るシステムの指針を決定することに等しい。

またアーキテクチャにおいて最も安定したコンポーネントは自社で意思決定できるビジネスロジックである。（ビジネス組織でなくても同様の指針は有るはずだ）

そして不安定な要素はフレームワークやDBMSなどの外部都合で変わりうるものだ。

そこまで押さえておけば例の図は自然と導出できるであろう。

そしてこれはアーキテクトは事業の方向性に関して知っておかないといけないという話でも有る。

目的と手段がひっくり返っていないか？

ソフトウェアを作るにあたってはなにか目的が有るはずである。

ビジネスロジックというが、実際はビジネスではないかもしれないが、ソフトウェアは何かしら目的を持って動作している。

これは文脈によってはバリューと言われるものでもあり、それが明確化されていないのはそれはそれで問題なのだが、それはビジネスサイドの話である。

フレームワークやRDBというのはその目的を実現するための手段に過ぎないのであって、バージョンアップ対応などは本来やりたいことではないはずである。

そう考えるとやはりこれらは本質ではなくコアから切り離されるべき末端の詳細な話である。

しばしば、どの言語が、どのフレームワークが生産性がいいかという議論を耳にする。

それに対して、自分のスタンスとしては「なんでもいいよ」である。

実際シビアな性能要件などがある場合は流石に選択肢が絞られるが、言語やフレームワークが全体生産性に影響するかというと疑問である。

これは現場によって違うのでただの憶測だが、実際の生産性のボトルネックとなっているのは要件定義、仕様変更、開発プロセスであることが多いのではないか？

言語やフレームワークによる最適化は、それ以外の構造的な問題が解決されてから向き合ってもいいはずだ。

おわりに

結局、柔軟なソフトウェアを作る上では、分割して依存関係を整理するという基本的なことを粛々とやるのが最も正解のようである。

これは変わるものと変わらないものを分けるという意味でも有る。

一部が不変で一部が変わるというわかりやすいものでもない。

あらゆる理由であらゆるものが変わるのだ。

カオスを避けるには変更に法則性を見つけて制御しないといけない。

この法則性は現場ごとに異なるので、現場にしかわからない。

だからアーキテクトは境界を常に見定める必要があり、これがアーキテクトの仕事の本質だと思う。