Architecture Decision Records — document significant technical decisions.
| # | Decision | Status | Impact |
|---|---|---|---|
| 0001 | Spring Boot 3 over Quarkus | Accepted | Framework choice |
| 0002 | Virtual Threads over WebFlux | Accepted | Concurrency model |
| 0003 | PostgreSQL over MongoDB | Accepted | Data store |
| 0004 | Apache Kafka over RabbitMQ | Accepted | Messaging |
| 0005 | Transactional Outbox for events | Accepted | Event consistency |
| 0006 | Clean Architecture domain isolation | Accepted | Code structure |
- Introducing a new technology or library
- Changing the database schema significantly
- Adding a new bounded context
- Changing communication patterns (sync → async)
- Any decision affecting multiple services or the template itself
Do NOT write an ADR for:
- Adding a standard CRUD endpoint within existing patterns
- Minor refactoring
- Bug fixes
Use the ADR format shown in existing ADRs above: Context, Options Considered (with Pros/Cons), Decision, Consequences, Validation.
NNNN-{kebab-case-title}.md — sequential numbering, never reuse numbers.
Next available: 0007