🦀

ソフトウェアアーキテクトのための意思決定術 の感想

2025/02/02に公開

書籍について

こちら
https://amzn.asia/d/4HUnbVu

Amazonでめっちゃ売れている!みんなも買おう!!
レビューに携わったの巻末に私の名前もある!

1章の冒頭で、アーキテクチャの失敗の多くは、アーキテクトの「知識不足」ではなく「判断力不足」で引き起こされている、と述べられております。
この書籍は、その「判断力」を鍛えるために必要な、アーキテクトが意識すべきトピックが「5つの質問」と「7つの原則」として述べられており、各章ではそれらをさらに技術的に実践していく方法が、ぎゅっと圧縮して語られています。

それゆえ、内容としては一部にかなり高度な部分があり、「これからはプログラミングだけじゃなくアーキテクチャにも関心を持とう!」くらいの初学者の方だと読んでいて挫折する部分が多いと思います。
ある程度現場でアーキテクチャに携わってきて、アーキテクチャの難しさに日々頭を悩ませている方々には、非常に学びになる内容です。

感想

なんといっても、著者が徹底して主張する「標準的な選択肢の限界を理解した上で、可能な限り標準を選択しよう」という方針に感動しました。

各章で何度も語られており、特に印象的だった部分を何件か引用させていただきます。

いわゆるバックエンドのAPIについて

私のお勧めは、HTTP+JSONをデフォルトのソリューションとして始め、やむを得ない理由が生じた段階でそこから離れるというアプローチだ。

コーディネーション層の設計について

「クライアントからフローを駆動する」か「別のサービスからフローを駆動する」のどちらかを選択しよう。ほとんどの場合、この2つの選択肢のいずれかで十分なはずだ。

分散トランザクションについて

トランザクションの範囲を可能な限り制限する。可能であれば、単一のサービス内に制限し、分散トランザクションを避ける。

というように、基本的に最新のイケてそうな小難しい実装なぞせずに、可能な限りシンプルに設計して実装することを徹底して伝えられています。
特に「マイクロサービス * トランザクション」については、多くの書籍では二相コミットやサーガなど、技術的に「これだけ頑張れば実現できるよ!」ということが語れる書籍が多い中、このような主張が前面に出ているのは非常に有益なことだと感じます。

ここまで私の感想だけ読むと、なんだかやる気のない選択肢を選んで楽をしているようにだけ受け取られるかもしれませんね...。

そうではなく、冒頭で語られた「判断力」というのが、この「標準的な選択肢」を外れる際に重要だ、ということが語られている書籍です。

少しでもレイテンシを減らすためにgRPCを採用する。
疎結合アーキテクチャを徹底するためにコレオグラフィを採用する。
複数MSAのデータの整合性を担保するためにサーガを実装する。

どれもそれ単体だけ見れば「間違っている」とは言えません。
ただ、「そのレイテンシは数ミリ秒でも減ると事業が成長するものですか?」「疎結合アーキテクチャは今この段階で徹底する必要はありますか?」「データの整合性は厳密に担保しなければ事業の損失を生みますか?」というような問いかけに、自信を持って答えることができるのか、というのは大事な観点です。
「標準的な選択肢」を外れる技術の採用もタダではありません。
実装当時はイケイケのアーキテクトがリードして開発できたとしても、その人が異動になった後もチームとしてそれらを運用し続けなければなりません。

しかし、時としてこのような「標準的な選択肢」を外れる技術の採用をすることが、プロダクトを成長させ事業に多くの利益を与えることもあります。

適切な時に適切な技術を判断し、投資収益率(ROI)を最大にすることが、アーキテクトに求められる役割ということです。

難しい...。

このような難しいことに悩まされるアーキテクトのために、この書籍は「5つの質問」と「7つの原則」を用いて、書籍のタイトルの通り意思決定に必要な要素を教えてくれます。

いい本。

そんな私も、現在プロダクトとしては初となるEvent Sourcingの導入を検討しているため、「深く考え、ゆっくり実装」しております...。

Discussion