こんにちは@p1assです。 タイトルの通り、『ソフトウェアアーキテクチャの基礎 エンジニアリングに基づく体系的アプローチ』を読みました。
本書はソフトウェアアーキテクチャに関する内容を網羅的にまとめたもので、アーキテクトのようなポジションを目指す人にとっての教科書的な存在です。 自分の今の興味関心にドンピシャの内容で、書籍の発売後にすぐ読み切ってしまいました。
この記事では、本書の感想を書こうと思います。 現在購入を検討している方の参考になれば幸いです。
ソフトウェアアーキテクチャはトレードオフがすべてだ。
本書における最も重要なメッセージは、ソフトウェアアーキテクチャの第一原則である 「ソフトウェアアーキテクチャはトレードオフがすべてだ。」 でしょう。
私はどうしてもアーキテクチャに対して「正解」を求めてしまう傾向にあります。 「ベストプラクティスやそれに準ずるものに従っていれば OK」という状況を目指したいと考えてしまいます。 しかし、そんな期待を持って本書を手に取っても、その願いが叶うことはありません。
本書では、全てのソフトウェアアーキテクチャにはトレードオフが存在することを前提に話を進めています。
例えば、アーキテクチャ特性(-ility)の章では、どのアーキテクチャ特性が、対象のプロダクトにとって最も重要なものであるかを特定し、どれが重要でないかを理解することが大事だとされています。 全てのアーキテクチャ特性を満たそうとしたアーキテクチャは、あらゆるビジネス上の問題を解決してくれるかもしれない。しかし、そのようなアーキテクチャは扱いにくい設計となり、うまく機能することはないと主張しているのです。
銀の弾丸を求めている人には辛い現実ですが、改めてトレードオフの現実に向き合うのにはピッタリです。 全てのソフトウェアアーキテクチャにはトレードオフが存在するという前提に立つと、トレードオフを全面に出した議論ができるようになります。
例えば、考えたアーキテクチャが解決することだけでなく、必ず存在するトレードオフ（つまりデメリットになるようなもの）が何なのかと考えることができるようになるでしょう。
他にも、そのトレードオフに対し、「妥当性を持ってアーキテクチャを決定するのに必要な材料は何か?」といったことも考えられるようになるはずです。
このように、全ての判断が「場合による」状況下での物事の考え方やプラクティスが紹介されているので、特定の人だけでなくソフトウェアアーキテクチャを考える多くの人にとって役に立つ本だと感じました。
様々な「〇〇アーキテクチャ」の比較
本書では、様々なアーキテクチャスタイルについて、それぞれのトレードオフを言及しながら紹介されています。
具体的には、次の 8 つのアーキテクチャについて紹介されています。
- レイヤードアーキテクチャ
- パイプラインアーキテクチャ
- マイクロカーネルアーキテクチャ
- サービスベースアーキテクチャ
- イベント駆動アーキテクチャ
- スペースベースアーキテクチャ
- オーケストレーション駆動サービス指向アーキテクチャ
- マイクロサービスアーキテクチャ
知っているアーキテクチャもあれば、知らないアーキテクチャもあるでしょう。 ここでは、それぞれのアーキテクチャの具体的な説明には言及しませんが、様々なアーキテクチャが紹介されているということを知ってもらえたらと思います。
本書のアーキテクチャの紹介の素晴らしい点は、それぞれのアーキテクチャに対して、13 個のアーキテクチャ特性に沿った評価表が書かれているところです。
例えば、レイヤードアーキテクチャでは、モジュール性やスケーラビリティは星 1、全体的なコストやシンプルさは星 5 と評価されています。 このような評価を見るだけでも、それぞれのアーキテクチャスタイルの違いやトレードオフを理解するのに役立つでしょう。
アーキテクチャ決定のアンチパターン
アーキテクチャの決定に関するアンチパターンは、個人的に本書の中で最も興味深かった内容の 1 つです。
本書では、次の 3 つのアンチパターンが紹介されています。
- 資産防御アンチパターン : 選択を誤ることを恐れて、アーキテクチャ決定を下すことを避けたり、先延ばしたりすること
- グラウンドホッグデーアンチパターン : ある決定が下された理由が分からずに、繰り返し何度も議論されてしまうこと
- メール駆動アーキテクチャアンチパターン : 人々がアーキテクチャ決定を見失ったり、忘れたり、あるいは決定されたことさえ知らなかったりするために、そのアーキテクチャ決定を実装できなくなってしまうこと
この 3 つのアンチパターンを見たときの感想は、「あ〜この状況よくあるわ〜」でした。 「ある PR のコメント上で議論が決着したけど、後々入ってくるメンバーはそれにたどり着く術がない」といった状況はよくあると思います。
こういった状況を整理し、はっきりとアンチパターンだと主張してくれる本書は、このような状況に陥らないようにするための対策の後押しになってくれると思います。
ここからは私独自の考えですが、私は「アーキテクチャは、自分がいなくなったとしても漸進的に改善していけるように工夫されていなければならない」と考えています。 ソフトウェアの要件は常に変化するので、たとえ今時点で最高のソフトウェアアーキテクチャを考えついたとしても、それは時間の経過によって最高のものではなくなってしまいます。 そのため、常にソフトウェアアーキテクチャは改善を続けていかなければなりません。
しかし、自分がいなくなったときにアーキテクチャ決定が引き継がれない環境は、このような取り組みの足かせになります。
アーキテクチャ決定が正しく伝わらない環境では、意図が分からず本来行くべき方向ではないに改善(改悪とも言う)してしまったり、逆に何も触れないでおこう、といった判断がなされる可能性があります。 この先に待っているのは溜まり続ける技術的負債の山です。
こういった事態にならないためにも、アーキテクチャ決定のアンチパターンは出来るだけ避けていきたいです。
おわりに
色々書いたんですが、本当にオススメできる本なのでぜひ買って読んでほしいです。 Evans の DDD 本のような古い時代に書かれた本とは違って、現代的な内容・訳なのですんなりと読めると思います。