読書備忘録：Clean Architecture 達人に学ぶソフトウェアの構造と設計
※ このブログのamazonリンクは、アフィリエイトリンクにより収入を得ています。
※ これは私個人の意見であり、会社の見解ではありません。
本の概要
アーキテクチャのルールはどれも同じである!
書いているコードが変わらないのだから、どんな種類のシステムでもソフトウェアアーキテクチャのルールは同じ。ソフトウェアアーキテクチャのルールとは、プログラムの構成要素をどのように組み立てるかのルールである。構成要素は普遍的で変わらないのだから、それらを組み立てるルールもまた、普遍的で変わらないのである。(本書「序文」より)
本を読んだ理由
terraformのアーキテクチャの議論を聞いていて、アーキテクチャ関連の知識が不足していたため
本書が現職のエンジニアによく読まれているため
本を読んだ際の前提知識
データアナリストやアナリティクスエンジニアとして働いている
データモデリングについて考えたことはあるが、アーキテクチャに関して検討するのははじめて
全体の感想
理解に難しい箇所も多かったですが、アーキテクチャーを考える上での前提を学ぶことができてよかったです。
一方で、個人的にはクリーンコードの方が読んで有意義でした。
「これまではアドホック分析が多く、アーキテクチャに関してはほぼ初めて考える」というケースでは、クリーンコードから読んだ方がいいかもです
本の備忘録
第1章 設計とアーキテクチャ
ソフトウェアアーキテクチャの目的は、求められるシステムを構築・保守するために必要な人材を最小限に抑えること
第2章 2つの価値のお話
ソフトウェア開発チームには、機能の緊急性よりもアーキテクチャの重要性を強く主張する責任が求められる
ソフトウェアの開発に関わった経験がないため、個人的にもアーキテクチャの重要性が腹落ちしていないように感じています。
第7章 単一責任の原則
単一責任の原則(SRP)は、アクターの異なるコードは分割するべきという原則だ
「コードをどう分割するべきか」という観点で検討したことがなかったので新鮮でした。
第15章 アーキテクチャとは？
ソフトウェアアーキテクチャの目的は、システムを単一のアクションで簡単にデプロイできるようにすることである。
保守の主なコストは、洞窟探検とリスクだ。(中略)アーキテクチャを慎重に考え抜けば、これらのコストは大幅に低下する。
第22章 クリーンアーキテクチャ
この章に関してはネガティブな意見もネット上に散見されます。
細かいルールにはいったん踏み込まずに、円の中心の「企業のビジネスルール」と「アプリケーションのビジネスルール」を把握してから詳細を詰めていこう、くらいのニュアンスで理解しています。
第25章 レイヤーと境界
この例は、アーキテクチャの境界があらゆるところに存在することを示している。我々アーキテクトは、それがいつ必要になるかに気を配らなければならない。
第27章 サービス：あらゆる存在
サービスは、アーキテクチャの境界に囲まれたひとつのコンポーネントの場合もある。あるいは、アーキテクチャの境界で分割された、複数のコンポーネントで構成されている可能性もある。
「必ずしも、サービスごとでアーキテクチャが分割されるわけではない」という点を、肝に銘じておきたいです。
第29章 クリーン組込みアーキテクチャ
Kent Beckが、ソフトウェアを構築する活動について、以下のように説明している。
まずは、動作させる。動作しなければ、仕事にならない
それから、正しくする。あなたは他の人が理解できるようにコードをリファクタリングして、ニーズの変化や理解の向上のためにコードを進化させていく
それから、高速化する。「必要とされる」パフォーマンスのためにコードをリファクタリングする
(組込みアーキテクチャとは関係ないですが、)昔のコードが理解しにくかったとしても、その時点でのベストプラクティスということを覚えておきたいです。
第30章 ~ 第34章
Javaに関してメインで書かれていると判断し、斜め読みで終わりました
あとがき
経験豊富な開発者たちが、私にアーキテクチャのことを教えてくれた。あなたがクリーンアーキテクチャを理解できたら、ほかの誰かの理解を手伝ってほしい。恩送りだ。
この記事が気に入ったらサポートをしてみませんか？