| 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）
