この記事は FOLIO Advent Calendar 2022の一日目です。
ソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析 を読んだので感想です。
※ この本は翻訳を担当された@snoozer05 さんから頂きました。ありがとうございます！
感想
マイクロサービス・サーガ・オーケストレーションといった個別の技術についてはある程度理解している人でも、いざ実システムに応用しようとすると「結局、マイクロサービスってどの単位で切るのがいいの？」みたいな疑問が次々出てきてしまう・・・といったことはよくある悩みだと思います。（本書では例として郵送通知とプッシュ通知とメール通知は通知サービスにまとめたほうが良いのか、個別にしたほうが良いのかなんて悩みが紹介されていました。）
（この疑問も含めた）様々なアーキテクチャに関する疑問の回答は「何が良いかは場合による」であり、実際に意思決定を行うためには様々なトレードオフについて考える必要があります。本書ではそういった「何が良いかは場合による」問題に対して、技術的選択肢の特徴を整理し、対立するトレードオフ関係を見出し、ビジネス上の価値・優先度・目的に照らし合わせ、後から変更しにくい事柄（＝ハードパーツ）について意思決定を行うためにどのような考え方をしていけばいいか、どのような議論を行えばいいかが記載されています。
議論パートは物語形式になっているのですが、いろいろな人（モノリスを分解したい人、DBを分散させたくない人、...)が自分の立場でメリット・デメリットを語り、挙句の果てに「マイクロサービスだからこうあるべき」、「こういう技術を使うのがモダンらしい」みたいな絵に書いたようなフワッとした会話が行われているところから話を着地させ、意思決定し、ADR(アーキテクチャデシジョンレコード）にまとめていく、という過程が読んでいて面白かったですし、実際の仕事でも役に立ちそうな現実味がありました。
マイクロサービスについてもそれありきではなく、「マイクロサービスにするとあなた達の問題は解決するんですか？」といった問いから初めて、マイクロサービスに伴い得るもの・失うものを技術的な視点から出発しビジネス的な価値につなげるところまで解説しています。
マイクロサービスではDBを共有しない（ので、共有は避けるべきだ！）という話もよくあると思いますが、本書ではDBを共有する形であるサービスベースアーキテクチャとの比較も踏まえ、「○○だからこうあるべき」ではなく「自分たちが求めているのが○○だから△△を採用する」といった正しい意思決定へ導きます。(注: マイクロサービスでDB共有を推奨しているわけではなく、サービスは分けるけどDBは共有する別のパターンもあるよねといった話です。)
また最終的には、（本書で登場するトレードオフを暗記するのではなく）それらのトレードオフを自分で整理し意思決定できるようにするための方法論も紹介されています。アーキテクトという役職は「どちらが良いかは場合による」問題に対して対立軸を見出し、ビジネス上の優先度と照らして意思決定を行っていく役職であるという筆者の思いを感じました。ともするとエンタープライズサービスバスとかコレオグラフィとかそういった概念・技術に詳しい人がアーキテクトだ！みたいな考えにもなりがちですが、後から変えにくいもの（＝ハードパーツ）の意思決定に携わるためには手段に精通した上でビジネス上の目的・優先度と照らして意思決定が出来るというのがより重要だというのは個人的にも頷けます。技に溺れたアーキテクトではなく、技を使いこなすアーキテクトになるための一歩としてこの本は非常に有用なのではないかと思いました。
逆に言うとマイクロサービスってなんだろうとか、サーガってそもそもなんだろうみたいな解説については（記載はあるものの）詳しくはないので別の本を読んでからの方が良いかもしれません。
手法面では、どのようにDBを分割していくか・分析データをどのように連携していくか（データレイク・データメッシュetc)などについても記載があるのが嬉しいところでした。
ということで、これからアーキテクトになりたい人・よりアーキテクトとして成長したい人にとってはかなり良い本だと思ったので気になったらぜひ！
