domain-design

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.md
• docs/gp/06-components.md — 実装コンポーネント一覧。テンプレート: templates/components-template.md
• docs/gp/09-configuration-knowledge.md — 構成の知識。テンプレート: templates/configuration-knowledge-template.md

次のステップの案内

次の活動として以下が推奨される:

• 「DSL記法の定義」（/dsl-definition）— まだDSLを定義していない場合
• 「実装」（/implement）— DSLも定義済みの場合、コード生成に進む