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
ADRs are:
- Proposed: In the process of being written and reviewed. Expected to change before merging to one of the statuses below.
- Accepted: Ratified and expected to be utilized going forward, or already complete depending on context and time of reading.
- Rejected: Not accepted but recorded to preserve history and the decision-making process; for reference. Likely seldom used as many ADs will transform during review.
- Deprecated: No longer expected to be in place, or abandoned.
- Superseded: Replaced by a future ADR, with appropriate annotation to the successor(s).
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 engineering leaders 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 amongst leadership before being adopted.
Once an ADR is recorded and accepted it is expected that any related documentation around architecture, deep dives, process, etc. is updated to reflect the decision(s) made.
ADRs
📄️ 0001 - Angular Reactive Forms
Context and Problem Statement
📄️ 0002 - Public API for modules
Context and Problem Statement
📄️ 0003 - Adopt Observable Data Services for Angular
Context and Problem Statement
📄️ 0004 - Refactor State Service
Context and Problem Statement
📄️ 0005 - Refactor Api Service
Context and Problem Statement
📄️ 0006 - Clients: Use Jest Mocks
Context and Problem Statement
📄️ 0007 - Manifest V3 sync Observables
Context and Problem Statement
📄️ 0008 - Server: Adopt CQRS
Context and Problem Statement
📄️ 0009 - Composition over inheritance
Context and Problem Statement
📄️ 0010 - Angular Modules
Context and Problem Statement
📄️ 0011 - Angular folder structure
Context and Problem Statement
📄️ 0012 - Angular filename convention
Context and Problem Statement
📄️ 0013 - Deprecate global request/response models
Context and Problem Statement
📄️ 0014 - Adopt Typescript Strict flag
Context and Problem Statement
📄️ 0015 - Short Lived Browser Services
Context and Problem Statement
📄️ 0016 - Move Decryption and Encryption to Views
Context and Problem Statement
📄️ 0017 - Use Swift to build watchOS app
Context and Problem Statement
📄️ 0018 - Feature management
Context and Problem Statement
📄️ 0019 - Adoption of Web Push
Context and Problem Statement
📄️ 0020 - Observability with OpenTelemetry
Context and Problem Statement
📄️ 0021 - Logging to Standard Output
Context and Problem Statement
📄️ 0022 - Authorization
Context and Problem Statement
📄️ 0023 - Identifying Integrated Clients
Context and Problem Statement