Architecture decisions
Architecture Decision Records (ADRs) document significant technical decisions made in Baseleg: what was decided, why, and what alternatives were considered.
When to write an ADR
Write an ADR when:
- Introducing or changing a major technology or framework.
- Establishing a cross-cutting architectural pattern or rule.
- Making a decision that would be hard to reverse or costly to change later.
- Adding a new component library to the UI.
For day-to-day implementation choices that follow established patterns, an ADR is not needed.
ADR status
| Status | Meaning |
|---|---|
| Proposed | Under discussion, not yet accepted |
| Accepted | Decision is in effect |
| Superseded | Replaced by a later ADR (linked) |
| Deprecated | No longer applicable |
Decision log
| # | Title | Status | Date |
|---|---|---|---|
| ADR-001 | Runtime and hosting | Accepted | 2026-04-28 |
| ADR-002 | Database choice | Accepted | 2026-04-28 |
| ADR-003 | Monorepo tooling | Accepted | 2026-04-28 |
| ADR-004 | Architectural layering | Accepted | 2026-04-28 |
| ADR-005 | Domain boundaries | Accepted | 2026-04-28 |
| ADR-006 | Testing strategy | Accepted | 2026-04-28 |
ADR template
# ADR-NNN: Title
Date: YYYY-MM-DD
Status: Proposed | Accepted | Superseded | Deprecated
## Context
What is the situation, constraint, or problem that requires a decision?
## Decision
What was decided? Be specific.
## Consequences
What are the outcomes, trade-offs, or follow-on constraints of this decision?
## Alternatives considered
What other options were evaluated, and why were they not chosen?