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

設定変数

${PROJECT_TYPE="Auto-detect|.NET|Java|React|Angular|Python|Node.js|Flutter|Other"} <!-- プライマリテクノロジー --> ${ARCHITECTURE_PATTERN="Auto-detect|Clean Architecture|Microservices|Layered|MVVM|MVC|Hexagonal|Event-Driven|Serverless|Monolithic|Other"} <!-- プライマリアーキテクチャパターン --> ${DIAGRAM_TYPE="C4|UML|Flow|Component|None"} <!-- アーキテクチャダイアグラムタイプ --> ${DETAIL_LEVEL="High-level|Detailed|Comprehensive|Implementation-Ready"} <!-- 含める詳細レベル --> ${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 == "Auto-detect" ? "以下を確認してプロジェクト構造を分析し、使用中のすべてのテクノロジースタックとフレームワークを特定します:

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

• ${ARCHITECTURE_PATTERN == "Auto-detect" ? "以下を分析してアーキテクチャパターンを決定します:

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

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

• 全体的なアーキテクチャアプローチの明確で簡潔な説明を提供
• アーキテクチャの選択肢から明らかな指導原理をドキュメント化
• アーキテクチャ境界とその実施方法を特定
• ハイブリッドアーキテクチャパターンまたは標準パターンの適応を記録

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

${DIAGRAM_TYPE != "None" ? `複数の抽象化レベルで${DIAGRAM_TYPE}ダイアグラムを作成します:

• 主要なサブシステムを示す高レベルのアーキテクチャ概要
• 関係と依存関係を示すコンポーネント相互作用ダイアグラム
• システム全体の情報の流れを示すデータフロー図
• ダイアグラムが理論的パターンではなく実装を正確に反映していることを確認` : "実際のコード依存関係に基づいてコンポーネント関係を説明し、以下の明確なテキスト説明を提供します:
• サブシステムの構成と境界
• 依存関係の方向とコンポーネント相互作用
• データフローとプロセスシーケンス"}

4. コアアーキテクチャコンポーネント

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

• 目的と責任:

  • アーキテクチャ内の主要な機能
  • 対処されるビジネスドメインまたは技術的な懸念事項
  • 境界と範囲の制限

• 内部構造:

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

• 相互作用パターン:

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

• 進化パターン:

  • コンポーネントの拡張方法
  • 変動ポイントとプラグインメカニズム
  • 設定とカスタマイズアプローチ

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

• コードベースで実装されたレイヤー構造をマップ
• レイヤー間の依存関係ルールをドキュメント化
• レイヤー分離を有効にする抽象化メカニズムを特定
• 循環依存またはレイヤー違反を特定
• 分離を維持するために使用される依存性注入パターンをドキュメント化

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

• ドメインモデルの構造と構成をドキュメント化
• エンティティ関係と集約パターンをマップ
• データアクセスパターン(リポジトリ、データマッパー等)を特定
• データ変換とマッピングアプローチをドキュメント化
• キャッシング戦略と実装を記録
• データ検証パターンをドキュメント化

7. クロスカッティングコンサーン実装

クロスカッティングコンサーンの実装パターンをドキュメント化:

• 認証と認可:

  • セキュリティモデルの実装
  • パーミッション実施パターン
  • アイデンティティ管理アプローチ
  • セキュリティ境界パターン

• エラーハンドリングとレジリエンス:

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

• ログとモニタリング:

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

• 検証:

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

• 設定管理:

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

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

• サービス境界定義をドキュメント化
• 通信プロトコルとフォーマットを特定
• 同期対非同期通信パターンをマップ
• APIバージョニング戦略をドキュメント化
• サービスディスカバリーメカニズムを特定
• サービス通信のレジリエンスパターンを記録

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

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

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

• ホストとアプリケーションモデルの実装
• ミドルウェアパイプラインの構成
• フレームワークサービス統合パターン
• ORMとデータアクセスアプローチ
• API実装パターン(コントローラー、最小限の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"}. 新規開発ブループリント

新機能の実装のための明確なアーキテクチャガイドを作成:

• 開発ワークフロー:

  • 異なるフィーチャータイプの開始ポイント
  • コンポーネント作成シーケンス
  • 既存アーキテクチャとの統合ステップ
  • アーキテクチャレイヤー別のテストアプローチ

• 実装テンプレート:

  • 主要なアーキテクチャコンポーネント用の基本クラス/インターフェーステンプレート
  • 新しいコンポーネント用の標準ファイル構成
  • 依存関係宣言パターン
  • ドキュメンテーション要件

• 一般的な落とし穴:

  • 回避すべきアーキテクチャ違反
  • 一般的なアーキテクチャミス
  • パフォーマンスに関する考慮事項
  • テストのブラインドスポット

このブループリントがいつ生成されたかについての情報を含み、アーキテクチャの進化に伴ってそれを最新に保つための推奨事項を提供します。"