configuration-knowledge

name	configuration-knowledge
description	フィーチャーの選択から実装コンポーネントへのマッピングルールを定義する。 「構成の知識を定義したい」「フィーチャーと実装の対応を整理したい」 「何を選んだら何が生成されるかを決めたい」といった要求があった場合に 使用する。DSL定義の成果物が存在することが前提。 ジェネレーティブプログラミングのドメイン設計活動。

構成の知識の定義

フィーチャーの選択が実装にどうマッピングされるかのルールを定義するスキル。 「この仕様を書いたら、どのコンポーネントがどう生成・変更されるか」を明確にする。 ジェネレーティブプログラミングのドメイン設計活動。

前提確認

• docs/dsl/notation.md が存在するか確認する
• docs/architecture/components.md が存在するか確認する
• 存在しない場合、先に関連する活動を行うことを推奨するが、必要に応じてこの活動から始めてもよい

手順

ステップ1: マッピングルールの定義

DSLの各記述項目について、それが実装にどう影響するかのルールを定義する。

• フィーチャー → コンポーネント: どのフィーチャーの選択がどのコンポーネントの生成・選択に対応するか
• パラメータ → 設定値: どのパラメータがどの設定ファイル・定数に対応するか
• 組み合わせ → 追加処理: フィーチャーの組み合わせによって必要になる追加のコード・設定

ステップ2: デフォルト構成の定義

• フィーチャーを何も指定しなかった場合のデフォルト構成を定義する
• デフォルト構成が制約に違反しないことを確認する

ステップ3: 変更シナリオの検証

代表的な変更シナリオでルールが正しく機能するか検証する:

• フィーチャーを1つ変更した場合、影響を受けるコンポーネントの特定
• フィーチャーを追加した場合、新たに生成されるコンポーネントの特定
• 制約違反となる構成を指定した場合のエラー検出

ステップ4: 成果物の出力

以下のファイルを出力する:

• docs/configuration/configuration-knowledge.md — 構成の知識。テンプレート: templates/configuration-knowledge-template.md

ステップ5: 次のステップの案内

次の活動として以下の実装活動が推奨されるが、必要に応じて他の活動に進んだり、以前の活動に戻って成果物を更新してもよい:

• 「実装コンポーネントの実装」（/component-implementation）
• 「ドメイン固有記法の実装」（/dsl-implementation）
• 「ジェネレータの実装」（/generator-implementation）