Decide on how to handle Bidirectional Decisions Dependencies

[Monstarrrr]

• Impact: 🟢 Low
• Status: 🔓 Deciding...

• Deciders & Confidence:

  • @purple-void (4.5 / 5️)
  • @seporterfield (4 / 5️)
  • @Monstarrrr (4 / 5️)

• Last updated: [DD-MM-YYYY]

Context

I don't see how we can avoid talking about other components in that architecture and how they would be affected and the restrictions they set on our choice of backend framework.

You're right, should we reference the dependencies and impact then?

Decision Drivers

• Scalability
• Ease of use
• Time cost

Considered Options

Impacts & Dependencies sections

Example

File for Decision-B in the case where Decision-C & Decision-D are dependent on Decision-B and Decision-B is dependent on Decision-A :

Decision-B.md (Frontend framework)

## Impacts
- #42 (Decision-C): API fetching method
- #55 (Decision-D): State management
## Dependencies  
- #30 (Decision-A): Backend framework

• 🟠 Worse scalability
  • Difficult to scale without having github action, which themselves can be challenging to maintain
• 🟢 Better ease of use
  • Result is super easy because we get direct links between impacted decisions
• 🟠 Worse time cost
  • Takes too long to setup and maintain compared to the benefits ( both short and long-term), assuming the impact of missing a dependency after a change in decision isn't causing major problems down the line

Related section

https://github.com/joelparkerhenderson/architecture-decision-record/tree/main/locales/en/examples/programming-languages#related

• 🟢 Better scalability
  • Doesn't require github actions to scale

Decision Outcome

Chosen option: Related section
Reason: The alternative is more time consuming to setup properly

[Monstarrrr]

I don't think option 1 scales at all using decisions-as-issues.
While we decided against using decisions-as-code before, mainly due to maintainability concerns.

[seporterfield]

Is our decision making such a strict process that we really need to worry about this?

It's fine to mention interplay between decisions. Could option 2 be "Mention in relevant arguments"?

[Monstarrrr]

It's fine, it can be that and some related section like https://github.com/joelparkerhenderson/architecture-decision-record/tree/main/locales/en/examples/programming-languages#related

[seporterfield]

Nah yeah you're right, a link and a short description of how the current decision is related to another suffices would be nice.

[Monstarrrr]

Add your confidence scores then move to Done.

[purple-void]

Nah yeah you're right, a link and a short description of how the current decision is related to another suffices would be nice.

yes, this makes sense