| name | architecture-design |
| description | フィーチャーモデルと概念モデルから共通アーキテクチャを設計し、 実装コンポーネントを確定する。「アーキテクチャを設計したい」 「実装コンポーネントを決めたい」「変化に強い構造を設計したい」 といった要求があった場合に使用する。フィーチャーモデリングの 成果物が存在することが前提。ジェネレーティブプログラミングの ドメイン設計活動。
|
共通アーキテクチャの設計と実装コンポーネントの確定
フィーチャーモデルの可変ポイントをアーキテクチャレベルでどう吸収するかを設計し、実装コンポーネントを確定するスキル。
ジェネレーティブプログラミングのドメイン設計活動。
前提確認
docs/domain/feature-model.md と docs/domain/concept-model.md が存在するか確認する- 存在しない場合、先にフィーチャーモデリング（
/feature-modeling）を行うことを推奨するが、必要に応じてこの活動から始めてもよい
手順
ステップ1: アーキテクチャスタイルの選定
フィーチャーモデルの可変性パターンに基づき、適切なアーキテクチャスタイルを選定する。
- システムの規模と複雑度を考慮する
- 可変ポイントの数と変化のタイプから、必要な柔軟性のレベルを判断する
- 候補となるアーキテクチャスタイル（レイヤード、クリーンアーキテクチャ、マイクロサービス等）を比較し、選定理由を記録する
ステップ2: 可変ポイントの実現方式の設計
フィーチャーモデルの各可変ポイントについて、アーキテクチャ上の実現方式を決定する。
各変化のタイプに対する方式:
- 差し替え型 → インターフェース抽象化、Strategy パターン、DI など
- 追加型 → プラグイン機構、レジストリパターン、設定による拡張ポイントなど
- パラメータ型 → 設定ファイル、環境変数、Feature Flag など
- 構造型 → モジュール境界の設計、データモデルの抽象化など
ステップ3: 実装コンポーネントの確定
システムを構成する実装コンポーネントを確定する。
- 各コンポーネントの責務を定義する
- コンポーネント間の依存関係を整理する
- どのコンポーネントが共通（固定）で、どのコンポーネントが可変かを明示する
- 可変コンポーネントの差し替え・追加のインターフェースを定義する
ステップ4: 技術スタックの選定
- 使用する言語、フレームワーク、ライブラリを選定する
- 選定理由（フィーチャーモデルの可変性への対応、チームのスキルセット等）を記録する
ステップ5: 成果物の出力
以下のファイルを出力する:
docs/architecture/architecture.md — アーキテクチャ設計。テンプレート: templates/architecture-template.mddocs/architecture/components.md — 実装コンポーネント一覧。テンプレート: templates/components-template.md
ステップ6: 次のステップの案内
次の活動として「ドメイン固有記法の定義」（/dsl-definition）が推奨されるが、必要に応じて他の活動に進んだり、以前の活動に戻って成果物を更新してもよい。
