第74回目のデッドライン読書会の投稿です。
昨年末から今年に向けて多忙につき、数回欠席してしまいました。
気合の復活です。
今回は「ソフトウェアアーキテクトのための意思決定術」ということで、
アーキテクトの基礎というより、より実践的な実務者向けの読み物という位置づけの書でした。
本書の特徴
私が把握した本書の特徴は以下の通り。
- 個々のアーキテクチャのパターンの説明書ではない
- ユースケースに沿い、◯◯が起きた場合の選択肢（5つの質問）と判断（7つの原則）を提示（後述）
- クラウドネイティブに特化しているわけではなくハードウェアの話題が含まれる
- 中級書。例えばマイクロサービスアーキテクチャの基礎は解説されない（コレオグラフィって？とか）
- システム全体像を「マクロアーキテクチャ」と呼んでいる
5つの質問と7つの原則
アーキテクトがソフトウェアアーキテクチャについて検討するうえでのポイントがこれ。本書で一気通貫して利用されている。大事なので写経させてもらう。
- 5つの質問：
- 市場投入に最適なタイミングはいつか？
- チームのスキルレベルはどの程度か？
- システムパフォーマンスの感度はどれくらいか？
- システムを書き直せるのはいつか？
- 難しい問題はどこにあるか？
- 7つの原則：
- ユーザージャーニーからすべてを導く
- イテレーティブなスライス戦略を用いる
- 各イテレーションでは、最小の労力で最大の価値を加え、より多くのユーザーをサポートする
- 決定を下し、リスクを追う
- 変更が難しいものは、深く設計し、ゆっくりと実装す
- 困難な問題に早期に並行して取り組むことで、エビデンスに学びながら未知の要素を排除する
- ソフトウェアアーキテクチャの凝集性と柔軟性のトレードオフを理解する
質問と原則のセットを持っておき、判断が必要な場合に振り返るっていう手法はいいですね。さまざまな意思決定の際に有効な考え方だと思います。
グレースフルデグラデーション
初めて聞いた用語も散見されたのでメモしておく。
「グレースフルデグラデーション」、上品な劣化。
なんらかの理由でシステムに不具合が起きた場合に、完全に停止するのではなく限定的な機能を提供するといった考え方。もっともイメージが湧くのはMDNの解説サイトの例だった。不特定多数のユーザーに利用されるWebアプリケーションにおいて「サポートされるブラウザのバージョン」より古いバージョンを利用した場合でも、限定的に劣化して（UI上見劣りするなど）、稼働することができるという考え方。
マイクロサービスにおける「前方互換性」
前方互換性なんて言葉あったんですね（後方互換、下位互換、上位互換は認識あったけど）。２つのサービス（AとB）が連携していたときに、片方のシステム（A）がバージョンダウンしても旧（B）が新（A）の通信を受け取ることができるという互換性です。前方互換を満たすための選択肢はいかが挙げられていた。（基本的には避けようが主たるメッセージだった）
- 旧（B）で新バージョンのメッセージ受け取るものの旧（B）が稼働するフォールバックパスを設定する
- 必要に応じて後でフォールバックパスを作る
- バージョンダウンを回避し、対策前進する
セキュリティへの対応
とてもいい教訓・メッセージがあったので抜き出す。セキュリティに関するほとんどの側面は特別な状況を除いてセキュリティ構成をゼロから実装することはお勧めしない。ってところ。
- セキュリティはリスクが高く、ミスの許される余地はほとんどない。
- そのアプリケーションがシンプルなユースケースだとしても、セキュリティに関する終わりのない新しい要求が続くことになる
- セキュリティ要件は、ミドルウェアまたはクラウドサービスプロバイダにおまかせすべき。ゼロから始めると多大な労力がかかるし結局うまくいかない
- 独自な実装より、使いにくかったとしても標準にのる。OpenID ConnectやOAuthなどの標準にのる
- 比較的安価なクラウドセキュリティソリューションがある
最近はSalesforce上での開発が多いので、自ら実装する機会はほとんどない。でもお客様からセキュリティの懸念についてはしばしばヒアリングを受けるため、改めて最新情報と取り組み方を考えておくのは重要だと思いました。
次は？
無事に読めてよかった！次はTidy First？
コメント