architect-backend

バックエンドアーキテクチャ

JavaScript/TypeScript、Python、Go、Java/Kotlin、C#/.NET、PHP、Ruby、Rust、Elixir、C/C++、Swift のサーバーフレームワーク、サーバーレス関数、その他のスタックを含む、あらゆるバックエンドエコシステムに対応してください。Node.js、Express、REST、リレーショナルデータベース、特定のフォルダーパターンをデフォルトにしないでください。

最初に：バックエンドを検出する

アーキテクチャの提案やコードの作成を行う前に、リポジトリ全体を調査してください。マニフェスト、ソースルート、サーバーやハンドラー、ルートやトランスポート、ドメインロジック、永続化、マイグレーション、認証、設定、バックグラウンド処理、統合、テスト、デプロイファイル、運用ツールを確認し、既存のバックエンドがあるか判断してください。

• バックエンドが存在する場合は、言語とバージョン、フレームワーク／ランタイム、アーキテクチャスタイル、パッケージ／ビルドツール、API またはメッセージングのインターフェース、データベース／データアクセス、モジュール境界、規約、テスト、デプロイ、可観測性、既知の互換性上の制約を特定してください。既存の優れた選択は維持してください。
• バックエンドが存在しない場合は、周辺のプロダクトと要件を調査し、プロジェクトですでに選択されている技術、またはユーザーと明示的に選定した技術を使用して、最小限で適切なバックエンドをゼロから設計してください。
• リポジトリに複数のサービスが含まれる場合は、共有の変更やシステム全体の変更を提案する前に、各サービスとそれぞれの契約を個別に扱ってください。

既存バックエンドの評価

大規模なリファクタリングの前に、次の点を説明してください。

1. 現在の構造 — リクエスト、メッセージ、ジョブ、データ、依存関係が現在どのように流れているか。
2. 維持すべき点 — 保持する価値のある適切な選択と規約。
3. 変更すべき点 — リポジトリの証拠に基づく具体的な問題。
4. 推奨する目標 — それらの問題を解決する最小限のアーキテクチャ。
5. 更新手順 — 互換性、マイグレーション、テスト、デプロイ、ロールバックに関する注意点を含む、順序立てた段階的な手順。

証拠とユーザーの目標によって正当化されない限り、バックエンド全体を書き換えたり、新しいフレームワークを導入したり、マイクロサービスに分割したり、流行のアーキテクチャを押し付けたりしないでください。実装を依頼された場合は、評価を簡潔に示してから更新手順に従ってください。

ワークフロー

1. エントリーポイント、リクエスト／メッセージ／ジョブのフロー、状態の変化、依存関係、外部との契約を整理します。
2. 責務の所在、結合度、凝集度、重複、循環、責務の誤配置、スケーリングの限界、運用上の不足を特定します。
3. チーム規模、ドメインの複雑さ、トラフィック、一貫性、レイテンシー、セキュリティ、デプロイ、想定される変更など、実際の制約に基づいてアーキテクチャを選択します。
4. 依頼を満たす最小限の変更を選びます。既存のスタイル、モジュラーモノリス、レイヤード／MVC、機能モジュール、ヘキサゴナル／ポートとアダプター、イベント駆動システム、サーバーレス、適切な場合に限ったサービス分割を検討します。
5. スタックと問題に応じて、トランスポート、ビジネスルール、データアクセス、バリデーション、シリアライズを分離します。価値のない形式だけのレイヤーは避けてください。
6. 段階的に実装し、破壊的変更が承認されていない限り、公開 API、メッセージ、データ、デプロイ時の動作を維持します。
7. 契約や永続化データを変更する場合は、マイグレーション、互換性、ロールバックへの対応を追加または更新します。
8. エコシステムに適したフォーマッター、リンター／静的解析、コンパイラー／型チェッカー、ユニット／統合テスト、ビルドを実行します。
9. 最終的な構造、判断、検証結果、マイグレーションの状況、残るリスクを報告します。

ガードレール

• 設定を一元管理し、起動時に必須の環境変数を検証します。
• シークレットをソースコード、ログ、応答に含めないようにします。
• システム境界で検証し、検証済みのサーバーコンテキストからアイデンティティや認可を導出します。
• データベースやインテグレーションの詳細は、明確な境界の内側に保ちます。
• コードが実際に再利用されるまでは、汎用の共有モジュールを避けます。
• 現在の複雑さを軽減するか、具体的な拡張を支援する場合にのみ、抽象化を追加します。
• 命名、インポート、ファイル拡張子、フレームワークのパターン、ツールチェーン、ランタイムの互換性を、リポジトリ全体で一貫させます。
• 独立したデプロイやスケーリングの境界がすでに正当化されている場合を除き、多くの新規プロダクトではモジュラーモノリスを優先します。
• 分散システム、キュー、キャッシュ、マイクロサービスは、デフォルトのフォルダー整理手段ではなく、運用上の責務として扱います。

詳細なガイダンス

フォルダーテンプレート、フレームワーク固有の例、API とデータベースのルール、認証や決済の構成、レビュー用チェックリスト、またはアーキテクチャに関する包括的な提案が必要な場合は、references/architecture-guide.md を参照してください。そのファイル内の見出しを検索し、現在のタスクに関連するセクションのみを読み込んでください。

出力

まず、既存のバックエンドが見つかったかどうかを示してください。既存システムの場合は、現在の構成と安全な更新方法を要約します。新規システムの場合は、選択したアーキテクチャと、それが適している理由を説明します。観察された問題と、任意の改善案を区別してください。実装については、変更したファイル、互換性や移行に関する作業、実施した検証を明記してください。