software-architecture

ソフトウェアアーキテクチャ

このスキルは、システムレベルの設計判断を行い、推進要因から根拠までを検証できる経路を残すために使用します。担当範囲はアーキテクチャ決定のワークフローであり、サブシステムの実装ではありません。

ワークフロー

1. 判断の枠組みを定めます。 望ましい成果、ステークホルダー、制約、判断の時間軸、可逆性、影響を受けるシステム、根拠の不足を明らかにします。規模、規制、レイテンシ、責任範囲に関する事実を捏造しないでください。
2. 品質特性をシナリオに落とし込みます。 重要なアーキテクチャ特性を挙げ、それぞれを観測可能なシナリオとして表現し、優先順位を付け、相反する要件を明らかにします。references/architecture-characteristics-and-tradeoffs.md を読み込みます。
3. 境界と構成を選定します。 シナリオとチームの運用能力に照らして、スタイル、トポロジー、デプロイの粒度を比較します。references/styles-topologies-and-granularity.md を読み込みます。
4. 責任範囲と結合度を検証します。 ポリシー、データ、変更、ランタイム、チームの境界を特定します。サービスの分割は既定の選択肢ではなく、仮説として扱います。references/coupling-modularity-and-data-ownership.md を読み込みます。
5. ランタイムの振る舞いを明確にします。 非同期または分散型のフローでは、権限、整合性、順序、再試行、重複、タイムアウト、一部障害、復旧、照合を明記します。references/distributed-workflows-and-consistency.md を読み込みます。
6. 記録して検証します。 決定と却下した代替案を templates/architecture-design-brief.md と templates/tradeoff-record.md に記録し、検討と承認には templates/architecture-review.md を使用します。references/evolution-fitness-functions-and-drift.md を使って、適合性を示す根拠と乖離への対応を定義します。
7. 実行の責任範囲を曖昧にせず、変更を計画します。 段階的な移行単位、共存に関する前提、引き継ぎ条件を特定します。references/migration-and-coexistence.md を読み込み、承認された移行を migration-engineering に引き継ぎます。
8. 規模に応じてファシリテーションを行います。 レビューの深さを、影響範囲、不可逆性、不確実性、チーム間への影響に合わせます。references/architecture-practice-and-facilitation.md を読み込みます。

出力要件

推進要因、ステークホルダー、制約、優先順位を付けたシナリオ、候補となる選択肢、明示的なトレードオフ、境界と責任範囲、ランタイムおよび障害時の振る舞い、運用上の影響、決定事項、根拠の不足、適合性の確認項目、段階的な移行単位、担当者を含むアーキテクチャ決定の概要またはレビューを作成します。決定済みの事項、未決の事項、フォローアップ作業を担当する専門家を明記してください。

責任範囲の境界

• 既存のコードベースをリバースエンジニアリングする場合、またはリポジトリの根拠からアーキテクチャを推測する場合は、software-architecture-analysis を使用します。
• インターフェース契約、スキーマ、互換性、API トポロジーを設計する場合は、api-design-and-evolution を使用します。
• データプラットフォーム、データプロダクト、データモデル、データガバナンスを設計する場合は、data-architect を使用します。
• サービス、統合、トランザクション、アプリケーションコードを実装する場合は、backend-engineering と関連するエンジニアリング担当者を利用します。
• クラウド、ネットワーク、CI/CD、コンテナ、シークレット、可観測性の基盤をプロビジョニングまたは運用する場合は、platform-engineering とそのツールの担当者を利用します。
• セキュリティ要件、脅威モデル、認可、シークレット、セキュリティの根拠を定義する場合は、secure-software-engineering を使用します。
• 長期保存する ADR の作成には adr-authoring を使用します。このスキルは、アーキテクチャ決定の背景とトレードオフ分析を提供します。
• 承認済みのシステム横断的な移行を実行する場合は、migration-engineering を使用します。このスキルでは、目標とする構成と境界が正当化されるかを判断します。
• 容量、単位コスト、負荷の根拠、SLO とコストのトレードオフをモデル化する場合は、capacity-and-cost-engineering を使用します。
• 劣化、フェイルオーバー、リストア、復旧の根拠を設計し、検証する場合は、resilience-and-recovery を使用します。
• 構造図の作成には、c4-diagramming または mermaid-diagrams を使用します。
• テクノロジーポートフォリオ、レーダー、または規模に応じたテクノロジーガバナンスの策定には、technology-radar を使用します。

使用しない場合

専門分野の担当者の代わりとして、コードレビューのワークフローとして、またはベンダー／ツールの運用手順書として、このスキルを使用しないでください。対象が単一のインターフェース、データプラットフォーム、実装、インフラストラクチャ、セキュリティ、容量、図、ADR、または移行に関する懸念だけである場合は、より範囲の狭い担当者を直接読み込んでください。アーキテクチャに関する問いが既存システムの事実に依存する場合は、software-architecture-analysis から始め、目標の判断を行うためにこちらに戻ってください。

リファレンスガイド

読み込む場合	リファレンス
品質に優先順位を付け、相反する結果を比較する場合	references/architecture-characteristics-and-tradeoffs.md
スタイル、デプロイトポロジー、または粒度を比較する場合	references/styles-topologies-and-granularity.md
モジュール性、結合度、境界、データの権限を検証する場合	references/coupling-modularity-and-data-ownership.md
分散ワークフロー、一貫性、または障害時の動作を設計する場合	references/distributed-workflows-and-consistency.md
レプリケーション、パーティショニング、調整、順序付け、またはトランザクション分離の仕組みを選択する場合	references/distributed-workflows-and-consistency.md、続いて DDIA mini reference。より深い仕組みの分析が必要な場合に限り、full reference を読み込んでください
適合性を示す根拠、ドリフトへの対応、または進化的な変更を定義する場合	references/evolution-fitness-functions-and-drift.md
共存を計画し、実行を移行エンジニアリングに引き継ぐ場合	references/migration-and-coexistence.md
アーキテクチャのワークショップ、レビュー、意思決定の進行を行う場合	references/architecture-practice-and-facilitation.md
出典の来歴と、ライセンス対象の書籍を変換する際の境界を確認する場合	references/source-index.md

DDIA を読み込む場合は、担当範囲の分担を明確にしてください。このスキルはシステムレベルのアーキテクチャ判断とそのトレードオフを担い、programming-principles は分散データの原則と仕組みの詳細を提供します。メッセージハンドラーの実装は backend-engineering に、API またはイベントの契約は api-design-and-evolution に、データプラットフォームの設計は data-architect に、実際に実施した復旧の根拠は resilience-and-recovery に割り当ててください。

完了

アーキテクチャ判断に説明責任を負う担当者が付き、明示的な代替案とその結果が示され、重要な主張ごとに根拠または不足している根拠が明記され、優先する特性の検証経路が定まり、専門分野の担当者への引き継ぎが完了した時点で終了してください。権限、セキュリティ、データの所有権、または運用上の根拠が不足している場合は、黙って解決せず、エスカレーションしてください。