結果予測性に効く記述自由度は三つに絞れる
記述自由度は無数に立てられるが、「実行前にコードを読んだ時点で、resource graphの形と各ノードの属性値がどう決まるかを読み取れるか」に直接効く軸に絞ると、三つになる。
- 抽象化の追加 — ユーザーが新しい抽象(任意ヘルパー関数 / クラス / 薄いwrapper)を足せるか。graph形状側ではmodule / Construct / Componentの切り出し、属性値側では値計算ヘルパー(命名規則 / 環境別パラメタ計算 / 文字列処理)や型抽象が該当
- 複数量の制御 — 同じ抽象や要素を何個展開するかを動的に決められるか。graph形状側では
for_each/countでresourceノード数を動かす、属性値側ではtags = { for k in keys: ... }のようなcomprehensionで属性内コレクションの要素数を動かす - 実装の切替 — どの実装を選ぶかを動的に決められるか。graph形状側では
sourceディレクトリやクラスの動的選択、属性値側では計算ロジックの動的選択(ストラテジ的な分岐)
選定基準は二つ。(i) resource graphの形または各ノードの属性値を変える自由度に直接効くこと、(ii)表記/抽象化の層で説明できること — 実行モデル・型・state・identityは別軸なので除外する。
この三つは構成記述系DSL全般の比較軸としても有用だが、IaC固有の偏りもある。「実装の切替」(import pathの動的性)は構成記述系DSL 11個すべてに当てはまる。「複数量の制御」も適用可能だが、graphを出力しないDSL(Pkl / CUE / Dhall)では「graphの個数」ではなく「最終valueの集合サイズ」として読み替える必要がある。「抽象化の追加」は普遍的だが、graph形状への影響はIaC以外では希薄。つまり三自由度そのものは一般的で、「graph形状を変えるか」という基準の方がIaC固有である。