31 lines
1.5 KiB
Markdown
31 lines
1.5 KiB
Markdown
# NFR Design Plan — Unit 04: API Shell & Integration
|
|
|
|
Dit plan beschrijft de stappen voor het technisch ontwerpen van de non-functional requirements voor de API Shell (Unit 04).
|
|
|
|
## NFR Design Stappen
|
|
- [x] Ontwerpen van de `ModuleOrchestrator` scanning logica.
|
|
- [x] Uitwerken van de Swagger configuratie voor JWT en module groepering.
|
|
- [x] Definiëren van de API Versioning configuratie (v1 prefix).
|
|
- [x] Ontwerpen van de globale CORS policy configuratie.
|
|
- [x] Vastleggen van de `Program.cs` extensie methoden voor module registratie.
|
|
|
|
## Vragen voor NFR Design (Unit 04)
|
|
|
|
### 1. Module Discovery Foutafhandeling
|
|
**Vraag 1.1**: Wat moet er gebeuren als een module niet geladen kan worden (bijv. door een ontbrekende afhankelijkheid)?
|
|
- A) **Fail Fast**: De hele API weigert op te starten. Meest veilig voor consistentie.
|
|
- B) **Soft Fail**: Log de fout, sla de module over en start de rest van de API wel op.
|
|
|
|
### 2. Route Prefixing
|
|
**Vraag 2.1**: Hoe moeten we de `/api/v1/` prefix afdwingen?
|
|
- A) **Expliciet**: In elke Controller route attribuut (bijv. `[Route("api/v1/[controller]")]`).
|
|
- B) **Globaal**: Via een `IApplicationModelConvention` in de Shell die alle routes automatisch prefixen.
|
|
|
|
### 3. Swagger Documentatie Locatie
|
|
**Vraag 3.1**: Waar moet de Swagger UI bereikbaar zijn?
|
|
- A) In de root (`/`).
|
|
- B) Op het standaard pad (`/swagger`).
|
|
|
|
## Volgende Stappen
|
|
Na beantwoording van deze vragen worden de technische ontwerpen gegenereerd in `aidlc-docs/construction/api-shell/nfr-design/`.
|