アーキテクチャ適応度関数
アーキテクチャ特性またはアーキテクチャ特性の組み合わせについて、客観的な整合性評価を行うための何らかの仕組み (1)
アーキテクチャ特性の整合性を客観的に評価するもの
『進化的アーキテクチャ ―― 絶え間ない変化を支える』 では、単に適応度関数と言われていた
評価には、メトリクスやユニットテスト、監視、カオスエンジニアリングなど、様々な仕組みが使われる
分類
アトミックな適応度関数 vs ホリスティックな適応度関数
1 つだけのコンテキストに対してか、共有コンテキストに対してか
ホリスティックなものは、セキュリティとスケーラビリティのような組み合わせに対するもの
トリガー式の適応度関数 vs 継続的なテスト
特定のイベントに基づいて実行されるか、継続的にモニタリングなどの形で検証がなされるか
モニタリング駆動開発 (MDD : Monitoring-driven development)
静的 vs 動的
静的な適応度関数は、固定化された結果 (成功 or 失敗、など)
動的な適応度関数は、追加のコンテキストに基づいて推移する定義に依存
例えば高スケールで動作する場合にはパフォーマンスメトリクスの低下を受け入れる、など
自動 vs 手動
一時的なもの
アップグレード中断テストなど
3 つのカテゴリ
主要なもの : 技術や設計を選択するうえで重要
関連性のあるもの : 機能レベルで考慮が必要だが、アーキテクチャ上の選択を誘導はしない
関連性のないもの
例
モジュール性に関するアーキテクチャ適応度関数
例えば、メトリクスツールの JDepend を活用して以下のことができる
パッケージ間に循環関係がないことをテスト
主系列からの距離を測る
ArchUnit で、レイヤー間の望ましい関係を定義
.NET 用には NetArchTest がある
Netflix の Chaos Monkey と Netflix Simian Army も適応度関数の例
『アナタはなぜチェックリストを使わないのか？』 におけるチェックリストと同様、適応度関数は統制のための重たい仕組みというよりは、アーキテクトが表現するアーキテクチャ指針を自動的に検証する仕組み
参考文献
1) ソフトウェアアーキテクチャの基礎 ―― エンジニアリングに基づく体系的アプローチ
進化的アーキテクチャ ―― 絶え間ない変化を支える