adastra_app/docs/decisions/0011-feature-domain-organisation.md

ADR 0011: Feature Domain Organisation

Date: 2026-04-26 Status: Accepted

Context

The application covers four independent functional areas, each with its own data model, API backend, and user audience:

• Skydive — jump logbook, statistics, QCM exam preparation.
• CMS — articles, pages, user profiles.
• E-commerce — product catalogue by category.
• Hero Wars — analytics dashboard for a game guild (static weekly snapshots).

Without an explicit organisational boundary, code from different domains would intermingle, making it harder to reason about and maintain each area independently.

Decision

Services, routes, and API prefixes are organised by domain:

• Services under src/app/core/services/<domain>/
• Routes composed from auth.routes.ts and noauth.routes.ts, with domain-specific guards (authGuard, adminGuard)
• API service domains: /skydive, /cms, /ecommerce, /herowars

This structure mirrors the backend's route grouping (src/routes/api/<domain>/), making the full-stack data flow traceable.

Consequences

• Positive: Each domain can be understood and modified independently.
• Positive: Consistent mapping between frontend service paths and backend API routes.
• Negative: Cross-domain features (e.g. shared auth, user profile) must be placed in core/ to avoid circular dependencies.
• Note: Hero Wars uses static JSON data files (src/files-data/) rather than live API calls, which is intentional — the data is updated manually via weekly snapshots.