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:
@@ -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)
|
||||
|
||||
Reference in New Issue
Block a user