TASHIKA Docs

Appearance

Architecture Decision Records (ADR) ​

本ドキュメントは、TASHIKA における ADR の採番ルール・フォーマット・管理プロセスを定義します。

NOTE

要件（What）: OP-001 保守性 / Architecture Decision RecordsADR 保管場所: docs/conventions/decisions/ ディレクトリ

目的 ​

重要なアーキテクチャ・技術的判断を「なぜそうしたか」「何を却下したか」「どんなトレードオフがあるか」と共に記録する。

ADR がない場合に生じる問題:

  • 後から参加したメンバーが「なぜこの設計か」を理解できない
  • 法改正・スケールアップ時に過去の判断の前提が分からず誤った変更をしてしまう
  • 設計の決定が再び議論されて時間を浪費する

ADR の採番 ​

ADR-{3桁連番}
  • ADR-001 から開始、ゼロ埋め3桁
  • 廃止された ADR は欠番とし、番号を再利用しない
  • ステータスが Superseded に変わっても ADR 自体は削除しない

フォーマット（テンプレート） ​

markdown
# ADR-NNN: タイトル

- **ステータス**: Proposed / Accepted / Deprecated / Superseded by ADR-XXX
- **日付**: YYYY-MM-DD
- **決定者**: （例: アーキテクトチーム）

## コンテキスト

なぜこの判断が必要になったか。背景・課題・制約を記述する。

## 決定

採用したアーキテクチャ・技術・パターンを一言で述べる。

## 理由

なぜこの決定をしたか。採用した理由を具体的に述べる。

## 却下した代替案

| 代替案 | 却下理由 |
|--------|---------|
| 案A    | 理由     |
| 案B    | 理由     |

## トレードオフ・リスク

採用によって生じる制約・デメリット・リスクを正直に記述する。

## 結果

この決定が影響するドキュメント・コンポーネント・要件を列挙する。

管理プロセス ​

フェーズ内容
1. 起票設計判断が必要になったタイミングで ADR を Proposed として起票
2. レビューPR レビュー（コードレビューと同様）で議論。代替案・リスクの妥当性を確認
3. 確定マージ時に Accepted へ更新
4. 廃止設計変更時に旧 ADR を Superseded by ADR-XXX に更新し、新 ADR を起票

初期 ADR 一覧 ​

IDタイトルステータス
ADR-001CQRS without Event SourcingAccepted
ADR-002PostgreSQL RLS によるマルチテナント分離Accepted
ADR-003スナップショット方式の申告履歴管理Accepted
ADR-004React SPA + BFF アーキテクチャの採用Accepted
ADR-005Sentry + OpenTelemetry ハイブリッドによるエンドツーエンドトレーサビリティAccepted
ADR-006Roselliパターンによるドメイン特化入力コンポーネントAccepted
ADR-007決済基盤に Stripe を採用Accepted