julien
c8e2fba13e
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.
47 lines
2.2 KiB
Markdown
47 lines
2.2 KiB
Markdown
# 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.
|
|
|
|
## Links
|
|
|
|
- Hero Wars uses static JSON files (`src/files-data/`) rather than live API calls — weekly snapshots updated manually. This is intentional and not a gap in the domain structure.
|
|
- Related to backend [ADR 0004](../../adastra_api/docs/decisions/0004-route-organisation-by-domain.md)
|