ADR
Architecture Decision Records
コード上で、アーキテクチャ(設計)の変遷の意図を管理する
ソースコードと一緒に管理
仕様ではなく意図を共有する
website
要は、decisionだけでなくcontextも残しておこう、というもの
ニーズ
目の前のコードの設計意図を知りたい
その変更の理由、背景を知りたい
項目
タイトル
context
今の状況、ビジネスの優先事項、技術的なものを中立的に事実を述べる
decision
コンテキストに対する決定実行
ステータス
合意していない場合は「提案」
合意された場合は「承認」
結果
決定を適用した後のコンテキスト
プラス、マイナス、中立のもの全てを記載
こういう項目は、色んな人が「これがいいぞ」ってのを個々に提案してるっぽい
コレ関係ある?
Working Backwards
https://aws.amazon.com/jp/builders-flash/202005/amplify-working-backwards/
Design Document
https://gist.github.com/daijinload/ae9fd5438a7f954106bbfcc0eed485c0
https://engineering.mercari.com/blog/entry/20220225-design-docs-by-mercari-shops/
#??
ASRって手法の名前?
architecturally-significant requirement (ASR)
ソフトウェアシステムのアーキテクチャに影響を与える要求のこと
計測可能である必要がある
スクボでやればええやんと感じるmrsekut.icon
↓の記事だけしか読んでないけど、これでうまく回るのが謎だ
参考
/kawasima/実践ADR
/kawasima/アーキテクチャ設計における垂直思考と水平思考
前提を疑う
アーキテクチャの「なぜ?」を記録する!ADRってなんぞや? - Qiita
https://tbpgr.hatenablog.com/entry/2017/02/22/080000
https://zenn.dev/souppower/articles/bfdf79069ae9a7
https://tech.route06.co.jp/entry/2023/06/07/120217
https://tech.route06.co.jp/entry/2023/07/04/130958