# ADR Templates 2020-06-09

## x

- https://adr.github.io/

## Templates

- https://github.com/joelparkerhenderson/architecture_decision_record/blob/master/adr_template_by_michael_nygard.md

# 題名 (Title)

## 状態 (Status)

提案、承認、却下、非推奨、置き換えなどのステータスは何ですか？

## 環境 (Context)

この決定または変更の動機となっていると私たちが見ている問題は何ですか？

## 決定 (Decision)

私たちが提案および/または行っている変更は何ですか？

## 結果 (Consequences)

この変更により、何がより簡単に、またはより難しくなりますか？

- https://github.com/joelparkerhenderson/architecture_decision_record/blob/master/adr_template_by_jeff_tyree_and_art_akerman.md

＃Jeff TyreeとArt AkermanによるADRテンプレート

これは、["Architecture Decisions：Demystifying Architecture" by Jeff Tyree and Art Akerman、Capital One Financial]（https://www.utdallas.edu/~chung/SA/zz-Impreso-architecture_decisions- tyree-05.pdf）。

* **問題 (Issue)**：対処しているアーキテクチャ設計の問題について説明してください。なぜこの問題に対処しているのか、疑問はありません。ミニマリストのアプローチに従って、ライフサイクルのさまざまなポイントで対処する必要がある問題のみに対処して文書化します。

* **決定 (Decision)**：アーキテクチャの方向、つまり選択した位置を明確に述べます。

* **ステータス (Status)**：保留中、決定済み、承認済みなどの決定のステータス。

* **グループ (Group)**：統合、プレゼンテーション、データなどの単純なグループを使用して、一連の決定を整理することができます。また、John KyaruziやJan van Katwijkのような、イベント、カレンダー、場所などのより抽象的なカテゴリを含む、より洗練されたアーキテクチャオントロジーを使用することもできます。たとえば、このオントロジーを使用して、システムがイベントの下で情報を必要とする場合の発生に対処する決定をグループ化します。

* **前提条件 (Assumptions)**：コスト、スケジュール、テクノロジなど、意思決定を行う環境の根本的な前提条件を明確に説明します。環境の制約（承認された技術標準、エンタープライズアーキテクチャ、一般的に採用されているパターンなど）によって、検討する代替策が制限される場合があることに注意してください。

* **制約 (Constraints)**：選択した代替案（決定）がもたらす可能性のある環境に対する追加の制約をキャプチャします。

* **役職 (Positions)**：検討した役職（実行可能なオプションまたは代替案）をリストします。これらは、多くの場合、長い説明を必要とし、時にはモデルや図も必要になります。これは完全なリストではありません。ただし、「について考えましたか？」という質問は聞きたくありません。最終レビュー中; これにより、信頼性が失われ、他のアーキテクチャ上の決定に対する疑問が生じます。このセクションは、他の人の意見を確実に聞くのにも役立ちます。他の意見を明示的に述べることは、その支持者をあなたの決定に参加させるのに役立ちます。

* **議論 (Argument)**：実装コスト、総所有コスト、市場投入までの時間、必要な開発リソースの可用性などの項目を含め、ポジションを選択した理由の概要を説明します。これはおそらく決定自体と同じくらい重要です。

* **含意 (Implications)**：REMAPメタモデルが示すように、決定には多くの含意が伴います。たとえば、決定によって、他の決定、新しい要件の作成、または既存の要件の変更が必要になる場合があります。環境に追加の制約を課します。お客様とスコープまたはスケジュールの再交渉が必要です。または追加のスタッフのトレーニングが必要です。決定の影響を明確に理解して述べることは、賛同を得て、アーキテクチャー実行のロードマップを作成するのに非常に効果的です。

* **関連する決定 (Related decisions)**：多くの決定が関連していることは明らかです。ここにリストできます。ただし、実際には、トレーサビリティマトリックス、意思決定ツリー、またはメタモデルの方が便利であることがわかりました。メタモデルは、複雑な関係（Roseモデルなど）を図で示すのに役立ちます。

* **関連要件 (Related requirements)**：決定はビジネス主導である必要があります。説明責任を示すには、意思決定を目的または要件に明示的にマッピングします。ここでこれらの関連要件を列挙できますが、トレーサビリティマトリックスを参照する方が便利です。各要件を満たすための各アーキテクチャの決定の貢献度を評価し、すべての決定にわたって要件がどの程度満たされているかを評価できます。決定が要件を満たすことに貢献しない場合は、その決定を行わないでください。

* **関連アーティファクト (Related artifacts)**：この決定が影響を与える関連アーキテクチャ、設計、またはスコープのドキュメントをリストします。

* **関連する原則 (Related principles)**：企業が合意した原則のセットを持っている場合、決定がそれらの1つ以上と一致していることを確認してください。これは、ドメインまたはシステムに沿った整列を確実にするのに役立ちます。

* **メモ (Notes)**：意思決定プロセスには数週間かかる場合があるため、社交プロセス中にチームが話し合ったメモや問題を記録しておくと便利です。

- https://github.com/joelparkerhenderson/architecture_decision_record/blob/master/adr_template_for_alexandrian_pattern.md

# アレクサンドリアパターンのADRテンプレート

## 前書き

* プロローグ（要約）
* ディスカッション（コンテキスト）
* 解決策（決定）
* 結果（結果）

## 仕様

* プロローグ（要約）
  * 要約する声明：
    * （ユースケース）のコンテキストで<br>
      直面している（懸念）<br>
      （オプション）に決めました<br>
      （品質）を達成するために<br>
      受け入れる（マイナス面）。
* ディスカッション（コンテキスト）
  * 戦場の勢力（技術的、政治的、社会的、プロジェクト）について説明します。
  * これは、私たちが解決しようとしている問題を説明する物語です。
* 解決
  * 決定により問題がどのように解決されるかを説明します。
* 結果
  * 長期にわたる決定の結果を説明します。
  * 機能しましたが機能しませんでしたが、変更、アップグレードなどが行われました。

- https://github.com/joelparkerhenderson/architecture_decision_record/blob/master/adr_template_for_business_case.md

# [解決した問題と解決策の短いタイトル]

* ステータス：[提案済み| 拒否されました| 受け入れられました| 非推奨| …| 置き換えられる[ADR-0005]（0005-example.md）] <！-オプション->
* 決定者：[決定に関与した全員をリストしてください] <！-オプション->
* 日付：[決定が最後に更新されたYYYY-MM-DD] <！-オプション->

テクニカルストーリー：[説明| チケット/発行URL] <！-オプション->

## コンテキストと問題ステートメント

[コンテキストと問題の説明を、2から3文で自由な形で説明します。質問の形式で問題を明確にしたい場合があります。]

## 決定要因<！-オプション->

* [ドライバー1、例：力、懸念に直面している…]
* [ドライバー2、例：力、懸念に直面している…]
* …<！-ドライバーの数は異なる場合があります->

## 考慮されるオプション

* [オプション1]
* [オプション2]
* [オプション3]
* …<！-オプションの数は異なる場合があります->

## 決定結果

選択されたオプション：「[オプション1]」。例えば、ko基準決定ドライバーを満たすオプションのみ| 力を解決する| …| 最高に出てきます（下記参照）]。

### ポジティブな結果<！-オプション->

* [品質属性の満足度の向上、必要なフォローアップの決定、…]
*…

### 否定的な結果<！-オプション->

* [例：品質属性の妥協、フォローアップの決定が必要、…]
* …

## オプションの長所と短所<！-オプション->

### [オプション1]

[例| 説明| 詳細情報へのポインタ| …] <！-オプション->

* 良い、[引数a]
* 良い、[引数b]
* 悪い、[引数c]
* …<！-長所と短所の数は異なる場合があります->

### [オプション2]

[例| 説明| 詳細情報へのポインタ| …] <！-オプション->

* 良い、[引数a]
* 良い、[引数b]
* 悪い、[引数c]
* …<！-長所と短所の数は異なる場合があります->

### [オプション3]

[例| 説明| 詳細情報へのポインタ| …] <！-オプション->

* 良い、[引数a]
* 良い、[引数b]
* 悪い、[引数c]
* …<！-長所と短所の数は異なる場合があります->

## リンク<！-オプション->

* [リンクの種類] [ADRへのリンク] <！-例：[ADR-0005]（0005-example.md）によって改良->
* …<！-リンクの数は異なる場合があります->

## Tools

- https://adr.github.io/madr/