Skip to main content

Architectural Decision Records

An Architectural Decision (AD) is a software design choice that addresses a functional or non-functional requirement that is architecturally significant. This might, for instance, be a technology choice (e.g., Java vs. JavaScript), a choice of the IDE (e.g., IntelliJ vs. Eclipse IDE), a choice between a library (e.g., SLF4J vs java.util.logging), or a decision on features (e.g., infinite undo vs. limited undo).

@Bitwarden​

The goal of introducing Architectural Decisions (AD) in the engineering team at Bitwarden is to steer development towards a maintainable and expandable code base. While at the same time striving for uniformity across all teams.

The AD will also serve as a base for proposing and planning technical debt.

Status definition​

  • In progress - ADR is ratified and we are in progress of adopting it across the project(s).
  • Standard - ADR is implemented and assumed to be standard.
  • Abandoned - ADR is abandoned, and/or replaced by another ADR.

Tags​

Please ensure each ADR contains a tag marking which projects they apply to (clients, mobile and/or server). Feel free to create more tags should the need arise.

Process​

While the process was originally created primarily for leads to discuss architectural decisions, it's important to us to keep the process open to suggestions from anyone. To that end, anyone is free to open a PR suggesting an AD. The suggestions will then be discussed to reach a general consensus between the leads before being adopted.

ADRs​