『Head First Software Architecture』に出てきたADR（Architectural Decision Record）について整理してみます。

ADR (Architectural Decision Record)

構成は次の通りです。

## タイトル
## 状態
## 文脈
## 決定
## 結果
## ガバナンス
## ノート

以下は、私が開発しているプロジェクトに適用しながら作成したADRの例です。実際のプロジェクトで作成したADRを基にしており、一部内容は理解しやすいように修正しています。

タイトル

番号は001から999まであり、タイトルは非常に慎重に書くべきだそうです。

001: チャットサービスのためにリレーショナルデータベース(PostgreSQL)を使用する: 承認、024により置き換え。

状態

状態には、意見募集、提案、承認があります。意見募集には必ず「回答期限」が必要です。

当然、開発過程では置き換えられる部分が出てくるため、次のような形式で書くそうです。

024: チャットサービスのデータベースとしてCassandraを使用することを決定: 承認、001を置き換え。

既存文書にも更新を入れ、新しい文書にも更新を入れる方式を取ることで、ADRが継続的に進化する文書であることを示します。

文脈

問題の背景と文脈を説明する部分です。

チャットサービスでは、リアルタイムメッセージ送信と高い書き込み処理量が重要です。PostgreSQLはリレーショナルデータベースとしてトランザクションと複雑なクエリを支援しますが、大規模チャットサービスでは書き込み処理量がボトルネックになる可能性があります。 また、チャットメッセージは一般的に単純なキー・バリュー形式で保存されるため、Cassandraのような分散型NoSQLデータベースのほうがこれらの要件に適している可能性があります。

決定

下した決定とその理由を説明する部分です。

チャットサービスはリアルタイムメッセージ送信と高い書き込み処理量を要求するため、Cassandraのような分散型NoSQLデータベースを使用することに決定しました。

結果

決定の結果と影響を説明する部分です。

Cassandraを使用することで、チャットサービスは高い書き込み処理量とリアルタイムメッセージ送信を可能にし、システムの性能と拡張性が向上しました。

ガバナンス

つまり、上でチームメンバーと時間をかけてADRを書いたあと、その決定が正しく実行されているか、継続して妥当かを確認する部分が必要だそうです。 『Evolutionary Architecture』という本にガバナンスに関する内容が出てくるようなので、今後勉強して更新します。

ADRはすべてのアーキテクチャ決定について文書化され、チームメンバー間のコミュニケーションと協業を促進します。

ノート

ADR自体に関するメタデータです。

• 原著者
• 承認日
• 承認者
• 最終修正日
• 修正者
• 最終修正

他の内容はEvent-Driven、DDD、Microservices、ソフトウェア工学の本にある内容と重なるため、別途書かないことにします。

おわりに

この本を中間試験の後に読んだため、ADR文書作業をできなかったのは残念ですが、次にチームプロジェクトがあれば、そのときは一度適用してみようと思います。

本に出てきた内容の一部は、2026年度のチームプロジェクトでEvent Stormingをしながら議論した内容と重なる部分が多く、自分たちなりにうまくできた部分も多かったと感じました。

次は、上で触れた進化的アーキテクチャや、他に面白い本があれば更新します。