Architecture Decision Records#
Each ADR captures one decision, the context it was made in, and the consequences. Format follows Michael Nygard’s template.
| ID | Title | Status | Date |
|---|---|---|---|
| 0001 | Authentication model | Accepted | 2026-07-03 |
| 0002 | Solution layout | Accepted | 2026-07-03 |
| 0003 | CI/CD pipeline | Accepted | 2026-07-03 |
| 0004 | Database migration strategy | Accepted | 2026-07-07 |
When to write one#
Write an ADR when the decision:
- Changes an interface other teams / systems depend on (auth model, envelope shape, health endpoint contract).
- Locks in a technology for a slice of the codebase (Serilog vs
ILoggerextensions, EF Core vs Dapper, xUnit vs NUnit). - Sets an invariant the codebase should enforce (nullable enable, TreatWarningsAsErrors, versioned routes only).
- Rejects an alternative that reasonable people would still argue for (why not microservices, why not RS256 for dev).
Not every commit needs an ADR. Small local refactors don’t.
Numbering#
- Sequential, zero-padded to four digits.
- Never reuse a number. If a decision is reversed, add a new ADR that supersedes the old one and mark the old one
Superseded by 00XX.