『ソフトウェアアーキテクチャの基礎』を読んだ
読んだので感想を書きます
1 章ではソフトウェアアーキテクチャとは以下の 4 つの組み合わせで構成されると言及しています
システム構造
実装スタイルの種類
マイクロサービス・レイヤードなど
アーキテクチャ特性
システムの成功基準を定めるもの
システムの機能とは直接関係しない
可用性、信頼性、テスト容易性、セキュリティ、回復性など
アーキテクチャ決定
システムをどの様に構築スべきかを定めるルール
設計指針
ルールではなくガイドライン
望ましいアプローチに関するガイドを提供する
私はソフトウェアアーキテクチャと言われるとまず上記のシステム構造(所謂アーキテクチャパターン)を思い浮かべるので、実際にはもっと広い範囲を指しているという点が、当たり前といえば当たり前かもしれないですが、参考になりました
またアーキテクトへの期待として、「最新のトレンドを把握し続ける」、「アーキテクチャ決定を下す」といった一般的なイメージと合致するものに加えて「事業ドメインの知識を持っている」、「対人スキルを持っている」、「政治を理解し、舵取りする」といったものもあり、要求されるスキルセットの幅広さが意外でした
書籍内でも頻繁に言及されていますが、ソフトウェアアーキテクチャはすべてがトレードオフです
エンジニアにとってベストなアーキテクチャが顧客にとってのベストではないことは往々にあり、ソフトウェアアーキテクトは両者を天秤にかけて意思決定する必要があります
正確に天秤の重さを図り、意思決定するためには事業ドメインの知識や政治的舵取りが必要になってくると解釈しました
2 ~ 8 章は基礎として、主にアーキテクチャ特性について触れられています
アーキテクチャ特性は様々ありますが、ステークホルダー間で定まっていないし、定義が様々で複合的すぎるので、ユビキタス言語を作って合意を取っていく必要があるとのことです
9 ~ 18 章はアーキテクチャスタイルの概要とアーキテクチャ特性の充足性について触れられています
レイヤードアーキテクチャはシンプルで全体的なコストは低いが弾力性や対障害性が低いのに対し、マイクロサービスアーキテクチャは全体的なコストは高く複雑だが弾力性・耐障害性・スケーラビリティに優れている、といった具合です
1 章で定義されたアーキテクチャ特性をそれぞれのアーキテクチャパターンがどの程度充足しているのか、について表形式でまとめられており参考になりました
19 章以降は少し思考のレイヤーを現場に近づけた、具体的なテクニックやソフトスキルについての紹介です
ソフトスキルに関してはあまり目新しい内容はなく ELASTIC LEADERSHIP や Team Topologies、Google のソフトウェアエンジニアリング等に記載されているような内容をソフトウェアアーキテクト向けにリファクタしたような印象です
最上位の思想(ソフトウェアアーキテクチャはトレードオフがすべて、どうやってよりなぜのほうがずっと重要)やソフトスキル面については共感しかありませんが、私がアーキテクチャに関する検討や意思決定については禄に経験もないので具体的な内容についてはあまり現実味を持って読み解くことはできませんでした
必要なときが来たら引っ張り出せるよう、頭の片隅には残しておきたいです
この記事が参加している募集
この記事が気に入ったらサポートをしてみませんか?