Technisch Ontwerp
Het Technisch Ontwerp beschrijft hoe OefenHub technisch wordt gerealiseerd op basis van de vastgestelde functionele en requirementsdocumentatie. Dit onderdeel werkt de volledige applicatie uit: authenticatie, autorisatie, domeinmodules, databaseontwerp, oefenmodules, oefenruns, communicatie, meldingen, realtime meekijken, PDF-export, readmodels, jobs, logging, security, frontend, privacy, beheerbeleid en teststrategie.
Het Technisch Ontwerp is geen vervanging van Functioneel Ontwerp, Software Requirements Specification, database-informatie, ERD of architectuurdocumentatie. Functioneel gedrag, centrale requirements, acceptatiecriteria en datamodelbroninformatie blijven in de daarvoor bedoelde documenten staan. Het Technisch Ontwerp beschrijft de technische vertaling daarvan naar solution-opbouw, projectgrenzen, DbContexts, schema’s, services, contracts, jobs, infrastructuur, logging, security en testbaarheid.
Positionering binnen de documentatieset
| Documentonderdeel | Rol ten opzichte van het Technisch Ontwerp |
|---|---|
| Functioneel Ontwerp | Functioneel kader, domeinregels, rollen, lifecycle en schermoverschrijdend gedrag. |
| Software Requirements Specification | Centrale requirements, prioriteiten, acceptatiecriteria en traceability. |
| Database-informatie | Primaire bron voor tabellen, kolommen, relaties, enumwaarden, snapshots en constraints. |
| ERD | Ondersteunende visualisatie van relaties en datamodelstructuur. |
| Architectuur | Architectuurbaseline, C4-context en richtinggevende architectuurkeuzes. |
| Schermdocumentatie | Schermspecifieke UI-context, labels, kolommen, tabs en lokale interacties. |
| Usecases | Actorinteractie, scenario’s, processtappen en alternatieve flows. |
| Oefenmodules | Moduleplatforminformatie, modulecontracten en concrete module-eisen. |
| Technisch Ontwerp | Technische implementatie, projectstructuur, modulegrenzen, EF Core-vertaalregels, jobs, infrastructuur, logging, security, frontend en teststrategie. |
Technische hoofdlijn
OefenHub wordt technisch uitgewerkt als een middel-zware modulaire monoliet: één deploybare .NET/Blazor-applicatie met één relationele database en één connectionstring, maar met expliciete project-, module-, DbContext- en schemagrenzen.
De basisprincipes zijn:
- één project heeft maximaal één eigen DbContext en daarmee één primair databaseschema;
- domeinmodules communiceren via publieke contracts, command-services, query-services, readers of expliciete workflowstappen;
- implementatieclasses, entities en DbContexts zijn standaard intern voor de module;
- cross-module verwijzingen zijn standaard soft links of soft link + snapshot;
- harde foreign keys worden primair binnen modulegrenzen toegepast;
- security en audit worden niet als aparte basisprojecten gemodelleerd, maar inhoudelijk wel volledig beschreven;
- scheduling heeft een eigen technisch project en schema voor job lifecycle, persistence, retries en TickerQ-integratie;
- concrete oefenmodules gebruiken de naamvorm
OefenHub.Modules.<ModuleCategory>.<ModuleName>; OefenHub.Webbevat UI-compositie, routing, componenten, viewmodels en state, maar geen domeinlogica of directe DbContext-toegang.
Hoofdstukken
- Intro, scope en uitgangspunten
- Architectuuroverzicht en solution-opbouw
- Applicatielagen, projectstructuur en dependency-richting
- Identiteit, authenticatie en rolcontext
- Autorisatie, policy's en server-side contextcontrole
- Domeinmodel en datamodel-overzicht
- Databaseontwerp, migraties, seeddata en constraints
- Oefencatalogus, niveaus, categorieën, oefeningen en modules
- Oefenmodulecontract en dynamische module-integratie
- Oefenruns, voortgang, resultaten, statistieken en PDF-brondata
- Leerling-, docent-, ouder-/voogd- en beheerderflows technisch
- Relatiebeheer, uitnodigingen en gedeelde oefeningen
- Berichten, systeemberichten, notificaties en privéthreads
- Meldingen/tickets en beheerafhandeling
- Realtime/live meekijken met SignalR
- PDF-export met QuestPDF
- Readmodels, tellers, badges, caching en materialisatie
- Background jobs, TickerQ en periodieke verwerking
- Logging, audit, securitylogging en technische foutafhandeling
- Security, infrastructuur, secrets en omgevingen
- Beheerbeleid, monitoring, backup/restore en operatie
- Performance, beschikbaarheid en fallbackgedrag
- Teststrategie, acceptatieherleidbaarheid en kwaliteitsgrenzen
- Frontend, Blazor, routing, state en componentopbouw
- Privacy, retentie, anonimisering en gegevensbescherming
- Open punten, ontwerpbesluiten en besluitenregister voor het Technisch Ontwerp
Registers
Uitwerkingsregels
Hoofdstukken van het Technisch Ontwerp mogen technische detailkeuzes, voorbeelden, tabellen, Mermaid-diagrammen en implementatiecontroles bevatten. Het Technisch Ontwerp dupliceert geen volledige tabeldefinities uit de database-informatie en introduceert geen nieuwe normatieve requirements buiten de Software Requirements Specification.
Wanneer een hoofdstuk te groot wordt of meerdere duidelijk gescheiden technische onderwerpen bevat, mag het worden opgesplitst in aanvullende subdocumenten of registers binnen het Technisch Ontwerp. De oorspronkelijke hoofdstukpagina blijft dan de inhoudelijke ingang en verwijst naar de detailpagina’s.
Bij iedere structurele technische wijziging moet worden gecontroleerd of ook Functioneel Ontwerp, Software Requirements Specification, database-informatie, ERD, schermdocumentatie, usecases, oefenmodule-documentatie of het Technisch Ontwerp zelf geraakt worden.