Tag
最近、APIに関する仕事をすることが多く、基礎知識を広げたり、理解があやふやな部分をしっかり理解するために読んだ。 マスタリングAPIアーキテクチャ モノリシックからマイクロサービスへとアーキテクチャを進化させるための実践的手法 目次 * 第1部 APIの設計・構築・テスト * 1章 APIの設計・構築・仕様化 * 2章 APIのテスト * 第2部 APIトラフィック管理 * 3章 APIゲートウェイ：外部トラフィック管理 * 4章 サービスメッシュ：サービス間トラフィック管理 * 第3部 APIの運用とセキュリティ * 5章 APIの展開とリリース * 6章 セキュリティ運用：脅威モデリング
技術選定やシステム設計などに関して意思決定をする際に、自分のカバー範囲や知っている情報だけだと全てを決めきれないことがある。もちろん仕入れられる情報は仕入れた上で意思決定しようとするのだけど、関係する他チームや関係者の方針やこれから決定される事項によって、自分たちの意思決定をどうすべきかが変わってくるような場合。 たとえば、エンジニアリングチームで何らかの機能に関する設計をする際に、その機能が具体的にどのようなユースケースで使われるのかを判断材料にしたいことがある。そして、ユースケースを考えるのがエンジニアリングチームではなく、ビジネスチームの責務だったとする。 そういう状況でたまに起きるあま
ADR (Architectural Decision Record) を書く機会がここ最近何度かあった。直近を振り返っての反省の話。 ADRを書くときは意思決定の選択肢やそれぞれの長所・短所を考え、それぞれを比較して最終的な結論を決めるのだけど、そればっかりに焦点を当ててしまうと、あまりうまくいかない。 具体的な選択肢について考えるよりも、意思決定をする必要が出てきた背景や目的、意思決定の結果がどう使われるのか（＝ユースケース）、意思決定に影響がある制約など、前段の部分についてしっかり情報収集・整理した上で言語化することがとても大事。 今回は、今ある選択肢を比較して何らかの結論を出そうと急ぎ