architecture-blueprint-generator

包括的なプロジェクトアーキテクチャブループリント生成ツール

構成変数

${PROJECT_TYPE="自動検出|.NET|Java|React|Angular|Python|Node.js|Flutter|その他"} ${ARCHITECTURE_PATTERN="自動検出|クリーンアーキテクチャ|マイクロサービス|レイヤード|MVVM|MVC|ヘキサゴナル|イベント駆動|サーバーレス|モノリシック|その他"} ${DIAGRAM_TYPE="C4|UML|フロー|コンポーネント|なし"} ${DETAIL_LEVEL="高レベル|詳細|包括的|実装対応"} ${INCLUDES_CODE_EXAMPLES=true|false} ${INCLUDES_IMPLEMENTATION_PATTERNS=true|false} ${INCLUDES_DECISION_RECORDS=true|false} ${FOCUS_ON_EXTENSIBILITY=true|false}

生成されるプロンプト

"アーキテクチャの一貫性を維持するための決定的なリファレンスとして機能する、コードベース内のアーキテクチャパターンを徹底的に分析した包括的な「Project_Architecture_Blueprint.md」ドキュメントを作成してください。以下のアプローチを使用してください：

1. アーキテクチャの検出と分析

• ${PROJECT_TYPE == "自動検出" ? "以下を調査して、プロジェクト構造を分析し、使用されているすべての技術スタックとフレームワークを特定します：

  • プロジェクトファイルと構成ファイル
  • パッケージの依存関係とインポートステートメント
  • フレームワーク固有のパターンと規約
  • ビルドとデプロイの構成" : "${PROJECT_TYPE} 固有のパターンとプラクティスに焦点を当てます"}

• ${ARCHITECTURE_PATTERN == "自動検出" ? "以下を分析して、アーキテクチャパターンを特定します：

  • フォルダー構成と名前空間
  • 依存関係の流れとコンポーネントの境界
  • インターフェースの分離と抽象化のパターン
  • コンポーネント間の通信メカニズム" : "${ARCHITECTURE_PATTERN} アーキテクチャがどのように実装されているかを文書化します"}

2. アーキテクチャの概要

• 全体的なアーキテクチャアプローチについて、明確で簡潔な説明を提供します
• アーキテクチャ上の選択に明らかな指針となる原則を文書化します
• アーキテクチャの境界と、それらがどのように適用されているかを特定します
• ハイブリッドなアーキテクチャパターンや標準パターンの適応があれば記載します

3. アーキテクチャの可視化

${DIAGRAM_TYPE != "なし" ? `複数の抽象化レベルで ${DIAGRAM_TYPE} 図を作成します：

• 主要なサブシステムを示す高レベルのアーキテクチャ概要
• 関係と依存関係を示すコンポーネント間の相互作用図
• 情報がシステム内をどのように移動するかを示すデータフロー図
• 図は理論上のパターンではなく、実際の実装を正確に反映していることを確認します` : "実際のコードの依存関係に基づいてコンポーネントの関係を説明し、以下について明確なテキストによる説明を提供します：
• サブシステムの構成と境界
• 依存関係の方向とコンポーネント間の相互作用
• データフローとプロセスの順序"}

4. 中核となるアーキテクチャコンポーネント

コードベースで検出された各アーキテクチャコンポーネントについて：

• 目的と責務：

  • アーキテクチャ内での主な機能
  • 対応するビジネスドメインまたは技術的関心事
  • 境界とスコープの制限

• 内部構造：

  • コンポーネント内のクラス/モジュールの構成
  • 主要な抽象化とその実装
  • 使用されているデザインパターン

• 相互作用パターン：

  • コンポーネントが他のコンポーネントとどのように通信するか
  • 公開および消費されるインターフェース
  • 依存性注入のパターン
  • イベントの発行/購読のメカニズム

• 進化のパターン：

  • コンポーネントをどのように拡張できるか
  • バリエーションポイントとプラグインのメカニズム
  • 構成とカスタマイズのアプローチ

5. アーキテクチャのレイヤーと依存関係

• コードベースで実装されているレイヤー構造をマッピングします
• レイヤー間の依存関係のルールを文書化します
• レイヤーの分離を可能にする抽象化メカニズムを特定します
• 循環依存やレイヤー違反があれば記載します
• 分離を維持するために使用されている依存性注入のパターンを文書化します

6. データアーキテクチャ

• ドメインモデルの構造と構成を文書化する
• エンティティの関係と集約パターンをマッピングする
• データアクセスパターン（リポジトリ、データマッパーなど）を特定する
• データの変換およびマッピングのアプローチを文書化する
• キャッシュ戦略と実装に言及する
• データ検証パターンを文書化する

7. 横断的関心事の実装

横断的関心事の実装パターンを文書化します。

• 認証と認可:

  • セキュリティモデルの実装
  • 権限適用のパターン
  • ID 管理のアプローチ
  • セキュリティ境界のパターン

• エラー処理と耐障害性:

  • 例外処理のパターン
  • リトライとサーキットブレーカーの実装
  • フォールバックとグレースフルデグラデーションの戦略
  • エラー報告とモニタリングのアプローチ

• ログとモニタリング:

  • インストルメンテーションのパターン
  • 可観測性の実装
  • 診断情報のフロー
  • パフォーマンスモニタリングのアプローチ

• 検証:

  • 入力検証の戦略
  • ビジネスルール検証の実装
  • 検証責任の分担
  • エラー報告のパターン

• 構成管理:

  • 構成ソースのパターン
  • 環境固有の構成戦略
  • シークレット管理のアプローチ
  • フィーチャーフラグの実装

8. サービス間通信のパターン

• サービス境界の定義を文書化する
• 通信プロトコルとフォーマットを特定する
• 同期通信と非同期通信のパターンをマッピングする
• API バージョニング戦略を文書化する
• サービスディスカバリのメカニズムを特定する
• サービス間通信における耐障害性パターンに言及する

9. テクノロジー固有のアーキテクチャパターン

${PROJECT_TYPE == "Auto-detect" ? "検出された各テクノロジースタックについて、固有のアーキテクチャパターンを文書化します。" : ${PROJECT_TYPE} 固有のアーキテクチャパターンを文書化します。}

${(PROJECT_TYPE == ".NET" || PROJECT_TYPE == "Auto-detect") ? "#### .NET のアーキテクチャパターン（検出された場合）

• ホストとアプリケーションモデルの実装
• ミドルウェアパイプラインの構成
• フレームワークサービスの統合パターン
• ORM とデータアクセスのアプローチ
• API 実装パターン（コントローラー、Minimal API など）
• 依存性注入コンテナの構成" : ""}

${(PROJECT_TYPE == "Java" || PROJECT_TYPE == "Auto-detect") ? "#### Java のアーキテクチャパターン（検出された場合）

• アプリケーションコンテナとブートストラッププロセス
• 依存性注入フレームワークの使用（Spring、CDI など）
• AOP の実装パターン
• トランザクション境界の管理
• ORM の構成と使用パターン
• サービス実装のパターン" : ""}

${(PROJECT_TYPE == "React" || PROJECT_TYPE == "Auto-detect") ? "#### React のアーキテクチャパターン（検出された場合）

• コンポーネントの合成と再利用の戦略
• 状態管理のアーキテクチャ
• 副作用の処理パターン
• ルーティングとナビゲーションのアプローチ
• データ取得とキャッシュのパターン
• レンダリング最適化の戦略" : ""}

${(PROJECT_TYPE == "Angular" || PROJECT_TYPE == "Auto-detect") ? "#### Angular のアーキテクチャパターン（検出された場合）

• モジュール構成の戦略
• コンポーネント階層の設計
• サービスと依存性注入のパターン
• 状態管理のアプローチ
• リアクティブプログラミングのパターン
• ルートガードの実装" : ""}

${(PROJECT_TYPE == "Python" || PROJECT_TYPE == "Auto-detect") ? "#### Python のアーキテクチャパターン（検出された場合）

• モジュール構成のアプローチ
• 依存関係管理の戦略
• OOP と関数型の実装パターン
• フレームワーク統合のパターン
• 非同期プログラミングのアプローチ" : ""}

10. 実装パターン

${INCLUDES_IMPLEMENTATION_PATTERNS ? "主要なアーキテクチャコンポーネントについて、具体的な実装パターンを文書化します:

• インターフェース設計パターン:

  • インターフェース分離のアプローチ
  • 抽象化レベルの決定
  • 汎用インターフェースと固有インターフェースのパターン
  • デフォルト実装のパターン

• サービス実装パターン:

  • サービスのライフタイム管理
  • サービスのコンポジションパターン
  • 操作実装のテンプレート
  • サービス内でのエラーハンドリング

• リポジトリ実装パターン:

  • クエリパターンの実装
  • トランザクション管理
  • 同時実行の処理
  • 一括操作のパターン

• コントローラー/API 実装パターン:

  • リクエスト処理のパターン
  • レスポンスフォーマットのアプローチ
  • パラメータの検証
  • API バージョニングの実装

• ドメインモデル実装:

  • エンティティ実装のパターン
  • 値オブジェクトのパターン
  • ドメインイベントの実装
  • ビジネスルールの適用" : "詳細な実装パターンはコードベース全体で異なることに言及します。"}

11. テストアーキテクチャ

• アーキテクチャに沿ったテスト戦略を文書化する
• テスト境界のパターン（ユニット、統合、システム）を特定する
• テストダブルとモックのアプローチを整理する
• テストデータ戦略を文書化する
• テストツールとフレームワークの統合について記載する

12. デプロイメントアーキテクチャ

• 構成から導出されるデプロイメントトポロジーを文書化する
• 環境固有のアーキテクチャ上の適応を特定する
• 実行時の依存関係解決パターンを整理する
• 環境間の構成管理を文書化する
• コンテナ化とオーケストレーションのアプローチを特定する
• クラウドサービス統合のパターンについて記載する

13. 拡張と進化のパターン

${FOCUS_ON_EXTENSIBILITY ? "アーキテクチャを拡張するための詳細なガイダンスを提供します：

• 機能追加パターン：

  • アーキテクチャの整合性を保ちながら新しい機能を追加する方法
  • 種類別に新しいコンポーネントを配置する場所
  • 依存関係導入のガイドライン
  • 設定拡張のパターン

• 変更パターン：

  • 既存のコンポーネントを安全に変更する方法
  • 後方互換性を維持するための戦略
  • 非推奨化のパターン
  • 移行アプローチ

• 統合パターン：

  • 新しい外部システムを統合する方法
  • アダプター実装のパターン
  • 腐敗防止層のパターン
  • サービスファサードの実装" : "アーキテクチャにおける主要な拡張ポイントを文書化します。"}

${INCLUDES_CODE_EXAMPLES ? "### 14. アーキテクチャパターンの例 主要なアーキテクチャパターンを示す代表的なコード例を抽出します：

• レイヤー分離の例：

  • インターフェース定義と実装の分離
  • レイヤー間通信のパターン
  • 依存性注入の例

• コンポーネント間通信の例：

  • サービス呼び出しのパターン
  • イベントの発行と処理
  • メッセージパッシングの実装

• 拡張ポイントの例：

  • プラグインの登録と検出
  • 拡張インターフェースの実装
  • 設定駆動型の拡張パターン

各例にはパターンを明確に示すのに十分なコンテキストを含めてください。ただし、例は簡潔に保ち、アーキテクチャの概念に焦点を当ててください。" : ""}

${INCLUDES_DECISION_RECORDS ? "### 15. アーキテクチャ上の意思決定の記録 コードベースから明らかな主要なアーキテクチャ上の意思決定を文書化します：

• アーキテクチャスタイルの決定：

  • 現在のアーキテクチャパターンが選ばれた理由
  • 検討された代替案（コードの変遷に基づく）
  • 決定に影響を与えた制約

• 技術選定の決定：

  • 主要な技術の選択とそのアーキテクチャへの影響
  • フレームワーク選定の根拠
  • カスタムコンポーネントか既製品かの決定

• 実装アプローチの決定：

  • 選択された具体的な実装パターン
  • 標準パターンの適応
  • パフォーマンスと保守性のトレードオフ

各決定について、以下を記録します：

• その決定を必要としたコンテキスト
• 決定を行う際に考慮された要因
• 結果として生じた帰結（肯定的なものと否定的なもの）
• 導入された将来の柔軟性または制約" : ""}

${INCLUDES_DECISION_RECORDS ? "16" : INCLUDES_CODE_EXAMPLES ? "15" : "14"}. アーキテクチャガバナンス

• アーキテクチャの一貫性がどのように維持されているかを文書化します
• アーキテクチャ準拠のための自動チェックを特定します
• コードベースから明らかなアーキテクチャレビューのプロセスを記録します
• アーキテクチャの文書化の慣行を文書化します

${INCLUDES_DECISION_RECORDS ? "17" : INCLUDES_CODE_EXAMPLES ? "16" : "15"}. 新規開発のためのブループリント

新しい機能を実装するための明確なアーキテクチャガイドを作成します：

• 開発ワークフロー：

  • さまざまな機能タイプの開始点
  • コンポーネント作成の順序
  • 既存アーキテクチャとの統合手順
  • アーキテクチャレイヤー別のテストアプローチ

• 実装テンプレート：

  • 主要なアーキテクチャコンポーネントの基底クラス/インターフェーステンプレート
  • 新しいコンポーネントの標準的なファイル構成
  • 依存関係宣言のパターン
  • 文書化の要件

• よくある落とし穴：

  • 避けるべきアーキテクチャ違反
  • よくあるアーキテクチャ上の誤り
  • パフォーマンスに関する考慮事項
  • テストの盲点

このブループリントが生成された時期と、アーキテクチャの進化に合わせて最新の状態に保つための推奨事項に関する情報を含めてください。"