アーキテクチャ設計の階層モデル
ビジネス目標、非機能要求から具体的な技法、ツールまでの意思決定を階層を分けて整理する。
table:アーキテクチャ設計の階層モデル
層 名称 例
L0 ビジネス目標 24時間365日のサービス提供を実現する
L1 非機能要求 サービスの年間稼働率を99.99%にする
L2 品質特性 可用性
L3 戦術 異常を検知する
L4 技法 ヘルスチェック
L5 ツール Prometheus Blackbox Exporter
教科書通りにやれば、ビジネス目標(L0)から順々に検討していって、最終的に具体的なツール(L5)を選定しようということになる。
だが、順々に検討していくアプローチは、あくまで「ひとつの子要素は必ずひとつの親要素に帰属する」というツリー構造を前提としている。実際には、以下のように多対多の関係が常に発生するため、単純なツリー分解だけでは全体像を正しく捉えきれない。
技法(L4) →戦術(L3)たとえばロギングは「異常を検知する」のみならず「攻撃から回復する」や「問題特定を支援する」にも用いられる。
ツール(L5)→技法(L4)Istio や Envoy などのプラットフォームは、単一の技法にとどまらず、複数の技法を横断的に実現する。
したがって、必ずしもトップダウンで設計を進める必要はなく、どのレイヤーから着手しても良いが、最終的にはL0からL5までの繋がりを明らかにしなくてはならない。この単純なツリー構造ではなく、セミラティス構造になるからこそ、「抽象と具体を行き来する」ことが重要とも言える。
https://gyazo.com/1ce1562b0fb00e10d7b9e33c2bed84a5
参考文献
L1 → L2
L2 → L3
L3 → L4
Pattern-Oriented Software Architecture
Patterns of Enterprise Application Architecture