『Clean Architecture 達人に学ぶソフトウェアの構造と設計』を読んだ。
最初期に自分が作成したソースコードを見て、酷いことになっていた。
賢者は歴史から学ぶらしいので、ソフトウェアのアーキテクチャについて本が無ければぜひ。
結局何の本？
ソフトウェア（とインタフェイス）アーキテクチャの本だよ。
具体例が載ってて、アーキテクチャのことをあんまり知らなくても、読みやすかった。
ハードウェアの性能は指数関数的に伸びるから設計は日進月歩だけど、ソフトウェアの考え方や設計は歴史から学んでいったら、変更に強いソフトウェアができるよねって話だった。
紙面の 3/5 程度が経験則の話題で、残りの 1/5 ずつがクリーンアーキテクチャ、補足的な感じの内容だった。
どう良かった？
アーキテクチャ概論
内容が重複するけど、比較的新しめの本でかつアーキテクチャを体系的にまとめた本っていうので良いと感じ。
SOLID が大切で、初期に実装したアプリケーションだと全然満たしていない。
密結合していたり、機能が複数あったり、機能変更をコード修正で済ませたり色々あったけど、変更がめっちゃしんどくなりますね・・・。
少人数だと、あまり意識しなくてもいいのですが、設計の際には意識できると便利だよなーという。著者は『アーキテクチャはプロジェクトの初期段階に決定したいと思うものだが、必ずしも他より適切なものになるとも限らない』と引用しているし、『優れたアーキテクチャとは、それが目的地ではなく旅路であること（中略）』としているので、本意としては、現場の裁量と目的地によって変えていこうという話だと思う。
クリーンアーキテクチャは？
SOLID のうちの D、依存関係逆転の原則[1]を活用する際の、モジュールの上位下位をどこで区切るかという話の時にクリーンアーキテクチャが出てくるという話だと理解した。
レイヤーを跨ぐ際に抽象クラスを挟むことで、レイヤーに依存せずにテストができる、テストができる。（大事なことなので）
このメリットは、厳密に言えば依存関係逆転の原則で得られるので、どうなんだろう。クリーンアーキテクチャじゃなくてもよいのだけれど。
あとは、フレームワークが青レイヤーに居るところ。フレームワークとは極力、結合せずに居たいということらしい。
技術書はいい
しっかりした本は、読み手のレベルに応じて得られる情報が変わってくるので、読めば読むほど味が出る。クリーンアーキテクチャもそうした味が出る本だった。ある程度技術者として成長した後に読み直すとまた、違った味が出る。その時には AI がソースコードを読み取って、最適なクラス図を引いてくれるかもしれないけれど。