Document Your Architecture Decisions with ADRs

Re:Document Your Architecture Decisions with ADRs by troyvit on Tuesday July 16, 2024 @11:16AM (#40977367)

I have two questions about this. First, what does the first entry look like? Most people don't have ADR started, so these decisions will come on top of an existing infrastructure. What's the first doc look like that holds that info?

Second, I wonder if it would also be good to include decisions NOT made or choices to NOT do a thing. ie.

Title: Set up separate S3-compatible instance for back-up image storage

Date when it occurred: 2024-07-16

Problem description: If our image server became inaccessible our site wouldn't have images.

Decision: Nah too expensive

Consequences of the decision: Really amazing ascii art from our photographers after [pick your AWS region] went down

[ Parent | on HN ]

Re:Document Your Architecture Decisions with ADRs by jacknews on Tuesday July 16, 2024 @11:26AM (#40977432)

Not the OP, but the 'decision' section is the place to describe trade-offs and rejected solutions, I think?

To start a new project, an overall 'design' or 'requirements' section. I'm not sure how you'd deal with an existing large code-base.

[ Parent | on HN ]

Re:Document Your Architecture Decisions with ADRs by meaboutsoftware on Tuesday July 16, 2024 @02:08PM (#40978826)

First answer: if you don't have any ADR yet, start with documenting the first decision that comes - don't go back in time to record 2 YO decisions.

Second: I described it as "Considered alternatives". There are 2 schools. One that puts it in "Decision" and the second one that puts it in "Considered alternatives " :)

I wouldn't document decisions that were not made as a separate ADR - it would be a mess after some time.

[ Parent | on HN ]