docs(adr): convert all ADRs to MADR 2.1.2 format

Rewrites all 7 backend ADRs from a custom structure to the MADR 2.1.2
template required by the VS Code ADR Manager extension: bullet metadata
(Status/Date), standardised section headings, "Chosen option: X, because Y"
wording, and explicit Pros/Cons blocks per option.
This commit is contained in:
2026-04-26 16:51:22 +02:00
parent d52795fde3
commit a9ef4cf629
7 changed files with 285 additions and 115 deletions
@@ -1,22 +1,46 @@
# ADR 0004: Route Organisation by Functional Domain
# Organise routes by functional domain
**Date:** 2026-04-26
**Status:** Accepted
* Status: accepted
* Date: 2026-04-26
## Context
## Context and Problem Statement
The API covers four independent functional domains (skydive, cms, ecommerce, herowars), each with distinct models, business logic, and frontend consumers. A flat route structure would make it difficult to reason about domain boundaries and onboard new contributors.
The API covers four independent functional domains (skydive, cms, ecommerce, herowars), each with distinct models, business logic, and frontend consumers. How should routes be organised to reflect these boundaries?
## Decision
## Considered Options
Routes are grouped under `src/routes/api/<domain>/` with a barrel index (`src/routes/api/index.js`). Each domain owns its routes, controllers, services, and models independently. The domain prefix is reflected in the API path (e.g. `/api/skydive/jumps`, `/api/cms/articles`).
* Domain-based organisation (`src/routes/api/<domain>/`)
* Flat structure (all routes at one level)
This structure mirrors the frontend's domain organisation (see frontend ADR 0011), making the full-stack data flow traceable: a frontend service under `core/services/skydive/` calls `/skydive/` routes, which map to `src/routes/api/skydive/`.
## Decision Outcome
Legacy `v1/`, `v2/`, `v3/` directories exist alongside the active routes as backup snapshots from earlier iterations. They are slated for removal once their contents are confirmed no longer needed (see ADR 0007).
Chosen option: "Domain-based organisation", because it makes domain boundaries explicit and mirrors the frontend's service structure, making the full-stack data flow traceable.
## Consequences
Routes are grouped under `src/routes/api/<domain>/` with a barrel index (`src/routes/api/index.js`). The domain prefix is reflected in the API path (e.g. `/api/skydive/jumps`, `/api/cms/articles`). Each domain owns its routes, controllers, services, and models independently. This structure mirrors the frontend's domain organisation (see frontend ADR 0011).
- **Positive:** Domain boundaries are explicit and enforced by directory structure.
- **Positive:** Consistent mapping between frontend service paths and backend routes simplifies debugging.
- **Negative:** Cross-domain features (shared auth middleware, user model) live in `src/middlewares/` and `src/database/models/` respectively, outside any domain folder.
### Positive Consequences
* Domain boundaries are explicit and enforced by directory structure.
* Consistent mapping between frontend service paths and backend routes simplifies debugging — a frontend service under `core/services/skydive/` maps to `src/routes/api/skydive/`.
### Negative Consequences
* Cross-domain features (shared auth middleware, user model) live in `src/middlewares/` and `src/database/models/` respectively, outside any domain folder.
## Pros and Cons of the Options
### Domain-based organisation
* Good, because each domain is self-contained and independently navigable.
* Good, because symmetric with the frontend service structure.
* Bad, because shared concerns need a neutral layer outside domain folders.
### Flat structure
* Good, because simpler for very small APIs.
* Bad, because domain boundaries become invisible as the API grows.
## Links
* Legacy `v1/`, `v2/`, `v3/` directories exist alongside `api/` as backup snapshots from earlier iterations — see [ADR 0007](0007-legacy-routes-removal.md) for their planned removal.
* Related to frontend [ADR 0011](../../adastra_app/docs/decisions/0011-feature-domain-organisation.md)