| name | domain-design |
| description | フィーチャーモデルから共通アーキテクチャを設計し、 実装コンポーネントを確定した上で、構成の知識（フィーチャー選択から 実装へのマッピングルール）を定義する。 「アーキテクチャを設計したい」「構成の知識を定義したい」 「フィーチャーと実装の対応を決めたい」といった要求があった場合に使用。 フィーチャーモデリングの成果物が存在することが前提。 ジェネレーティブプログラミングのドメイン設計活動。
|
| user_invocable | true |
ドメイン設計（アーキテクチャ + 構成の知識）
フィーチャーモデルの可変ポイントをアーキテクチャレベルでどう吸収するかを設計し、
実装コンポーネントを確定した上で、フィーチャー選択から実装へのマッピングルールを定義する。
ジェネレーティブプログラミングのドメイン設計活動。
前提確認
docs/gp/02-feature-model.md と docs/gp/04-constraints.md が存在するか確認する- 存在しない場合、先にフィーチャーモデリング（
/feature-modeling）を行うことを推奨する
手順
パート1: アーキテクチャ設計
ステップ1: アーキテクチャスタイルの選定
- システムの規模と可変性パターンに基づき、適切なアーキテクチャスタイルを選定する
- AIによるコード生成が前提の場合、静的構成（生成時に可変性を解決）が基本方針
ステップ2: 可変ポイントの実現方式の設計
各変化のタイプに対する方式を決定する:
- 差し替え型 → コードフラグメント選択、インターフェース抽象化
- 追加型 → 拡張ポイント、プラグイン機構
- パラメータ型 → 型パラメータ、設定値
- 構造型 → モジュール境界の設計
ステップ3: 実装コンポーネントの確定
- 各コンポーネントの責務を定義する
- コンポーネント間の依存関係を整理する
- 共通（固定）コンポーネントと可変コンポーネントを明示する
- 可変コンポーネントのバリアントを列挙する
パート2: 構成の知識
ステップ4: マッピングルールの定義
DSLの各記述項目が実装にどう影響するかのルールを定義する:
- フィーチャー → コンポーネント: どのフィーチャーがどのコンポーネントに対応するか
- パラメータ → 設定値: パラメータが言語別にどう変換されるか
- 組み合わせ → 追加処理: フィーチャーの組み合わせで必要になる追加処理
ステップ5: デフォルト構成の定義
- フィーチャーを何も指定しなかった場合のデフォルト構成を定義する
- デフォルト構成が制約に違反しないことを確認する
ステップ6: 変更シナリオの検証
代表的な変更シナリオでルールが正しく機能するか検証する:
- フィーチャーを1つ変更した場合の影響範囲
- フィーチャーを追加した場合に新たに生成されるコンポーネント
- 制約違反の検出
成果物の出力
以下のファイルを出力する:
docs/gp/05-architecture.md — アーキテクチャ設計。テンプレート: templates/architecture-template.mddocs/gp/06-components.md — 実装コンポーネント一覧。テンプレート: templates/components-template.mddocs/gp/09-configuration-knowledge.md — 構成の知識。テンプレート: templates/configuration-knowledge-template.md
次のステップの案内
次の活動として以下が推奨される:
- 「DSL記法の定義」（
/dsl-definition）— まだDSLを定義していない場合
- 「実装」（
/implement）— DSLも定義済みの場合、コード生成に進む
