アーキテクチャ決定記録
ADRは、18か月後に誰かが既に解決した疑問をなぜ解決されたのかを知らずに再び開くことがないように、またコンテキストが変化した際に決定を意図的に再検討できるようにするために存在します。
保存場所
docs/adr/NNNN-短いタイトル.md のように、連番で保存します。ディレクトリ内で次の番号とハウステンプレートを確認し、テンプレートが存在する場合はそれに従ってください。
テンプレート
# NNNN. <決定の形式でのタイトル：「注文サービスにAurora PostgreSQLを使用する」>
日付: YYYY-MM-DD
ステータス: 提案 | 承認 | NNNNによって置き換え | 非推奨
決定者: <名前またはチーム>
## コンテキスト
<どのような力が働いているか：要件、制約、現在の課題、期限、コンプライアンス、
チームスキル、コスト枠。2〜4段落。事実であり、意見ではありません。>
## 決定
<1〜2文、現在形：「私たちは…します」>
## 検討したオプション
### オプションA: <名前>
メリット / デメリット / 概算コスト / 運用負荷
### オプションB: <名前>
…
## 結果
<何が容易になり、何が難しくなり、何を今行う必要があるか（移行、トレーニング、
新しいランブック）、何をリスクとして明示的に受け入れているか。>
## フォローアップ
- [ ] <具体的なタスクと担当者（分かっている場合）>
執筆ガイダンス
- コンテキストは、新人が決定を読む前に問題が現実的であると同意するように書きましょう。
- オプションは同じ軸で比較しましょう：コスト、運用負荷、ロックイン、チームの習熟度、納期、セキュリティ/コンプライアンス。数値がある場合はそれを記載してください（月額コスト見積もり、RTO/RPO、スループット）。
- 採用しなかったオプションの強みについても正直に書きましょう。選択肢を風車（論破しやすい弱い論点）として扱うADRは信頼されません。
- 結果には否定的なものも含みます。「現在、2つのデータベースをバックアップする必要がある」というようなものはそこに記載します。
- 2ページ以内に収めましょう。スパイク調査、ベンチマーク、チケットへのリンクを貼り、インラインで埋め込まないようにしましょう。
- 置き換える場合は、古いADRのステータスを更新し、双方向にリンクを貼りましょう。
$ARGUMENTS が与えられた場合
それをタイトルとして使用し、そこからファイル名を生成します。