分厚かった。
TL;DRとしては、
- アーキテクトかくあるべしについて書かれた本
- 実践的というよりかは、汎用的な話が広範囲で書かれてる感じ
- 基礎って書いてるけど、いわゆる駆け出しエンジニア向けではない
って感じ。
一エンジニアがコード書きながら「ここのコードどうまとめよかっな〜」とか「あのフレームワークかな〜」っていうレベルというより、もっと上位のレイヤーで「サービス全体のアーキテクチャが〜」とか「構成として冗長性が〜」みたいな話。そもそもコードを書く開発者と、この本の対象であるアーキテクトは別の位置づけだったりする。
3部構成
- はじめに
- 第1部: 基礎
- アーキテクトとは、その役割はどうあるべきか
- アーキテクチャとは
- どういう事柄に注意を払うべきか
- 第2部: アーキテクチャスタイル
- イベントベースとかマイクロサービスとか、具体的な設計方法について
- （たぶんこの本のメイン）
- 第3部: テクニックとソフトスキル
- 第1部を実践するための方法について
- エンジニアとどう接するべきかとか
という構成になってて、個人的には序章とか第1部が一番良かったかなという感じ。
実際にアーキテクトとして働いてるわけではないので、ざっくりとしたガイドラインやら前フリにあたる部分のほうが、読み物として丁度いいというか。
以下、特に気になった章だけまとめ。
1章 イントロダクション
- ソフトウェアにおけるアーキテクチャとは
- この4つによって構成されるもの
- システムの構造 = どういうスタイルで構成されてるか
- アーキテクチャの特性 = いわゆるイリティについて
- アーキテクチャによる決定 = 遵守されるべきルール
- 設計の指針（ガイドライン） = ルールよりは緩いガイド
- こうした決定を下し、ガイドするのがアーキテクト
- 技術トレンド、事業ドメイン、対人スキル、政治などなど幅広い理解が必要
- アーキテクチャは良し悪しではなく、トレードオフしかない
2章: アーキテクチャ思考
- アーキテクチャを決めるのがアーキテクト
- その決定を元に設計を行いコードを書くのが開発者
- この責任の異なる2者のコラボレーションが重要だという話
- アーキテクトは技術的な幅が優先される
- 一般的には、深さよりも幅
- 開発者は、幅よりも深さが要求されがち
- ただし一定の深さも必要
- チームに溶け込んで、自らもコードを書くべき
- 未知の未知を、未知の既知にどう変えていくか
9章: 基礎
- 巨大な泥団子とは
- https://en.wikipedia.org/wiki/Big_ball_of_mud
- いわゆるクソコードの塊
- アーキテクトはこれを避けるのが使命
- 分散アーキテクチャの誤信
- サービス間のネットワークが信頼できるとかレイテンシがないとか
- その他の課題
- ロギング
- トランザクション
- バージョン管理
- こうしたトレードオフを知らずに、分散アーキテクチャに手を出していけない
23章: 交渉とリーダーシップのスキル
- アーキテクトの決定に対する異議をどうコントロールするか
- vs ステークホルダー
- vs 他のアーキテクト
- vs 開発者
- いわゆる交渉術
- コストの話は最後の手段
- 人によって声のかけ方を変える
- プログラマティックでありつつ、ビジョナリーでもあるべき
- チームに溶け込みリーダーシップを発揮する
まとめ
ソフトウェアアーキテクチャはトレードオフがすべてだ
これに尽きる。額にいれて飾りたい。
ちょっとした設計をするときとかでも、正解を求めすぎる気持ちはわからないでもない。けど結局そこに正解はなく、トレードオフがあるだけなので、淡々と取捨選択して残ったやつを拾い上げれば良いんやなと。ただ取捨選択できるだけの手札は揃えておく必要があって、選球眼も養っておかないといけない。
そんなこんなあれこれ調べてると、Microsoftが出してるAzureのドキュメントサイトが圧倒的知見の塊で、いろいろよかった。
Azure アプリケーション アーキテクチャの基礎 - Azure Architecture Center | Microsoft Docs