本記事ではソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析の第1章～第4章をベースに、モノリスからのサービス分割を検討するときに役立つポイントを整理する。 すべての組織に当てはまる“銀の弾は存在しないが、「どんなトレードオフを見極めるべきか」を理解することで、より納得感のあるアーキテクチャを設計できるかもしれない。 1. 「ベストプラクティス」は存在しない —...
アーキテクチャ戦略について考える ソフトウェア開発において、必ずしもCTOやアーキテクトといった明確なポジションにいなくても、「アーキテクチャ戦略の必要性」を感じ、考える機会がある。 「現場で技術的な方針をまとめたいが、どこから手をつけたらよいかわからない」 「将来の拡張性や組織の成長を踏まえたアーキテクチャにしたい」 「既に蓄積した技術的負債にどう向き合えばよいか知りたい」 本記事では、こう...
GraphQL federationについて調べたことをまとめる。 GraphQL Federationとは GraphQL Federationは、複数のGraphQLサービスを統合するための方法である。 GraphQLのマイクロサービスのようなもので、単一のGraphQLエンドポイントとして複数のGraphQLサービスを利用することができるようにするアーキテクチャパターンである。 GraphQ...
ソフトウェアアーキテクチャメトリクス ―アーキテクチャ品質を改善する10のアドバイスを読んだ。 ソフトウェアに関するメトリクスの観点について複数の著者が語っている。副題の通り各著者ごとのアドバイスであり、それぞれの章ごとで詳細までには深入りされてはいないが、アーキテクチャのメトリクスについて観点を知る取っ掛かりとして良い。 メトリクスの定義をするためのアプローチとしてGQMアプローチを紹介している...
アーキテクトの教科書 価値を生むソフトウェアのアーキテクチャ構築を読んだ。 タイトル通りまさに教科書といった内容で、アーキテクトが知るべき領域について網羅されている。 ソフトウェアアーキテクチャに焦点を当てた話が割合として多い。 注釈や良書紹介、参考文献が充実しているので、この本を起点に学びを広げることができる。 ...
Tidy First? ―個人で実践する経験主義的ソフトウェア設計を読んだ。 130ページしかないのですぐに読める。 コスト・収益・結合・凝集の観点で、"整頓"をするか？を考えさせてくれる本。 主張が端的でわかりやすいと感じた。 個人的にはコスト・収益の見積もりが難しく、技術者としての手腕が問われるなぁと思った。 特に、貨幣経済のアプローチで考えを示しているいくつかの章が面白か...
ソフトウェアアーキテクトのための意思決定術 リーダーシップ／技術／プロダクトマネジメントの活用を読んだ。 この本は訳文レビューに参加していた本で、献本を頂いてから再度読み直した。 アーキテクトの意思決定という部分にフォーカスを当てているところが画期的であり、アーキテクチャの設計に向かう人にとって学びがある内容になっている。 本書では、アーキテクチャの不確実性に立ち向かうためのツールとなる5つの質問...
freee 技術の本 freeeにおけるマルチプロダクト開発を読んだ。 業務系SaaSだと、共通業務（申請・承認）というドメイン領域で切り出せるのか、なるほど。申請・承認といってもコンテキストが違うとワークフローが違ったり、扱うデータも当然違うと思うので、難しそう。権限や通知と比べると抽象化が難しそうな機能分割っぽさがある。基盤としては申請に関する内容は扱わないようにしているらしい。扱わないよう...
マスタリングAPIアーキテクチャ ―モノリシックからマイクロサービスへとアーキテクチャを進化させるための実践的手法を読んだ。 冒頭の章でC4ダイアグラムやADRの解説が入っているのが良かった。この本で語られるアーキテクチャの話はそれらの手法を使って説明されている。 APIアーキテクチャのパターンやテスト、運用、セキュリティなどについて書かれている。 WebにおいてAPIに触れないということは皆無だ...
概要 信頼性のパターンについてAzure、AWS、GCPの提唱するパターンに基づいてまとめる。 信頼性とは ユーザー（システムやアプリケーション）が期待する機能を提供し続けることができる性質のことである。 信頼性を支える特性 信頼性は次のような特性によって支えられる。 可用性：システムが利用可能であること 耐久性：データが失われないこと 耐障害性：障害が発生してもシステムが機能し続けること 回復...