Files

T

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

Rewrites all 12 frontend 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.

2026-04-26 16:50:34 +02:00

2.2 KiB

Raw Blame History

Organise code by functional domain

Status: accepted
Date: 2026-04-26

Context and Problem Statement

The application covers four independent functional areas with distinct data models, API backends, and user audiences: Skydive, CMS, E-commerce, and Hero Wars. Without explicit organisational boundaries, code from different domains would intermingle, making each area harder to reason about independently. How should the codebase be structured?

Considered Options

Domain-based organisation (one folder per functional area)
Flat feature-based organisation (one folder per component type)

Decision Outcome

Chosen option: "Domain-based organisation", because it mirrors the backend's route grouping, making the full-stack data flow traceable, and allows each domain to be understood and modified independently.

Services are placed under src/app/core/services/<domain>/, API prefixes are /skydive, /cms, /ecommerce, /herowars, and routes are composed from auth.routes.ts and noauth.routes.ts with domain-specific guards.

Positive Consequences

Each domain can be understood and modified independently.
Consistent mapping between frontend service paths and backend API routes simplifies debugging.

Negative Consequences

Cross-domain features (shared auth, user profile) must be placed in core/ to avoid circular dependencies.

Pros and Cons of the Options

Domain-based organisation

Good, because domain boundaries are explicit and enforced by directory structure.
Good, because mirrors the backend route grouping — frontend core/services/skydive/ maps to backend src/routes/api/skydive/.
Bad, because shared cross-domain concerns need a neutral core/ layer.

Flat feature-based organisation

Good, because all components of the same type are co-located.
Bad, because domain boundaries are invisible — mixing domains is too easy.

2.2 KiB Raw Blame History