読み終わってから何かメモを残そうと思ったけれども、書きたいことは書きたい時に書くのが良い気がした。
読み始めたきっかけとしては、アーキテクトという役割が気になったため。
世の中にはモノリスやマイクロサービスなど、いろんなアーキテクチャスタイルがあるけれども、それぞれどういう特性を持っていて、どういうコンテキストで使い分けるのかが気になっていた。
時代の流れ的にモノリスよりマイクロサービスという風潮は感じたりするけれども、ではなぜマイクロサービスを選択するのかという理由が重要だったりする。
と思いながら、何か参考になりそうなソースがないか調べたらちょうど本が出版されたので、読んでみたという感じ。
で、読んでみたところ、結構発見があって面白い。
アーキテクチャは技術的な側面から決定するというよりは、ビジネス的な要求がインプットになっていて、ビジネスの特性を満たすようなアーキテクチャを選ぶというのは、なるほどという感じ。
たとえば、ユーザからのリクエストが瞬間的に増えるような場合には、弾力性やスケーラビリティが重要となり、それを実現するためのアーキテクチャスタイルが選択される。
あるいは、拡張機能が重要となるような場合には、拡張性を実現するためのアーキテクチャスタイルが選択されるといった感じ。
そういうと、簡単に聞こえるけれども、実際には正解はなく、あらゆる側面を総合的に分析して、トレードオフを検討した上でアーキテクチャを決定し、決定した後も継続的に改善するような営みは求められてくる。
割とシニアなエンジニアが、ぬるっとアーキテクチャ決定をしていて、本書の中で述べられているようなグラウンドホッグデーパターン（アーキテクチャ決定の理由が明確に共有されておらず、定期的に理由が問われる）に陥っている状況は少なくない気がする。
レイヤーやモジュール等に関するアーキテクチャ決定をADR（Architecture Decision Record）という形で明文化し、共有することで、なぜその決定がなされて、保持されているのかが分かるようにするのはとても重要な感じがした。
アーキテクチャに関して、「どうなっているか」を把握することはできても、「なぜ」を把握できない場面は結構あったりする。
という感じで、もう少しで読み終わります。