ADR
ADRは特定のアーキテクチャ決定を記述した1-2ページ程度のテキストファイルからなる。
基本的には以下の5つを記載する：
title タイトル
単なるテキストだけでなく、連番でidを振っておくと参照しやすい
ADR-XXXX のような
status ステータス
提案、承認、破棄という3つのステータスがあれば十分
提案済みのADRが別のADRに取って代わられることはない
目的が同じであるなら提案済みのADRを直接書き換えるべき
承認は議論が済んでおり、これに従って実装していい状態であることを意味する
破棄は決定が変更され、別のADRに取って代わられたことを意味する
破棄されたADRと代替のADRは将来の開発者が辿りやすいよう、破棄に関連するADRのレコードIDを記載し、相互リンクすべきである
RFC廃止時の Obsoletes XXX, Obsoleted by XXX といった記述がイメージしやすい
大きい組織でADRのドラフトを作ってコメントを広く募集したい場合は「提案」の前に「コメント募集」（RFC）ステータスを用意しても良い
その場合はステータスに募集期限をあわせて記載すること
1つの会議体で告知すればほぼ済むような状況なら不要だろう
context コンテキスト
背景と問題点について簡潔に説明し、幾つか実例を列挙する
decision 決定
アーキテクチャ決定とその根拠について記述する
肯定的、かつ断言的に書く
consequences 影響
この決定によって生ずるトレードオフと、そのトレードオフを割り出した分析を明記する
利点と欠点を明記し、利点が上回ることを説明する
テンプレートの一貫性と簡潔さが保たれてさえいれば他の節を加えてもいい
コンプライアンスは、そのアーキテクチャ決定がどのようにアーキテクチャ統制されるかを記述する 手動で行うか、適応度関数を実装するか
自動化する場合、どのように実装するか、プロダクトの改修にどのようなものが必要か
テストとして実装すると記載するなら、加えてテストの内容、テスト箇所、テストの実行方法などを記載する
avashe.iconコンプライアンスだと分かりづらいので、「統制」セクションにした方がよさそう
備考
メタデータを載せる
オリジナルの著者
承認日、承認者
初版から更新された内容とその経緯、日付
例えば本文中で追記するとき「更新 2XXX-01-01：～」といった感じで始めた方がいいよという意味
gitなどを使う場合でも、上記のようなサポートできない情報は載せておくとよい
例えば「代替案」の節を加え、当時検討していた他の競合アーキテクチャについての詳細な分析を残しておくことも有用
運用の問題として、ADRの提案者が直接承認してしまっていい場合と上位決定者の承認が必要な場合があり、そのエスカレーションの基準について決めておくことが重要である
コスト、チーム間の影響、セキュリティの観点について基準を設定しておくと良い
コストは金額でざっくり見積もるとよい
実装に参加するメンバーの工数を割り出し、そこに会社の平均的なフルタイム社員の収入を乗算することで工数を金額に変換できる。そこにライセンスや機材などの購入費用を足せば全体をコストを金額で見積もることができる。
基準が合意されたらADRのリポジトリにそれを明記すること
一応補助ツールとしてADR-toolsがあり、その使い方について説明してくれるブログがある ただ、それをつかうほど複雑でもない。gitリポジトリを使い、レコードのテンプレートを作り、その後0003-example-decision.mdというようにソートだけ気を配ってレコードを保存していけばいいだけ。あとはチームの雰囲気に合わせて提案、レビュー、マージなどの手順を詰めていけばいいだろう。
アプリケーションは製品についてのADR
インテグレーションはアプリ-システム間の通信や、アプリ-アプリ間の通信など、単体に収まらない横断的なADR
エンタープライズはすべてのシステム、アプリケーションに影響するグローバルなADR
例えば、システムデータベースへのすべてのアクセスは所有しているシステムからのものに限られるなど
命名は例なので自由にしていい
avashe.iconインフラ屋（ここではシステムと呼ばれているが）も影響範囲が横断しないものはアプリケーションにあたるのかな？