37 lines
964 B
Markdown
37 lines
964 B
Markdown
# ADR-004: Configuration Bootstrap and Provider Abstraction
|
|
|
|
Status: Accepted
|
|
Date: 2026-07-03
|
|
|
|
## Context
|
|
|
|
Configuration must initially come from mock JSON and later from backend API without changing consumers.
|
|
|
|
## Decision
|
|
|
|
Introduce configuration provider abstraction behind ConfigService.
|
|
|
|
- ConfigService is the only configuration entrypoint.
|
|
- Consumers depend on typed ConfigService selectors only.
|
|
- Provider implementation is swappable:
|
|
- MockBootstrapProvider
|
|
- ApiBootstrapProvider
|
|
- Frontend calls GET /bootstrap when API provider is enabled.
|
|
- Frontend does not pass tenant id.
|
|
|
|
## Consequences
|
|
|
|
Positive:
|
|
|
|
- Source-agnostic configuration usage.
|
|
- Mock-to-backend transition with minimal change surface.
|
|
|
|
Negative:
|
|
|
|
- Requires strict prohibition of direct JSON imports in components/services.
|
|
|
|
## Compliance Requirements
|
|
|
|
- No code outside ConfigService may load bootstrap JSON.
|
|
- No page/widget/component may access configuration files directly.
|