Leerling-, docent-, ouder-/voogd- en beheerderflows technisch

11.1 Doel van dit hoofdstuk

Dit hoofdstuk beschrijft hoe de rolgebonden OefenHub-flows technisch worden samengesteld uit de eerder beschreven modules, services, autorisatiecontroles, readmodels en UI-compositie. Het hoofdstuk introduceert geen nieuwe functionele eisen, maar vertaalt de functionele rolflows naar technische flowpatronen binnen de middel-zware modulaire monoliet.

De rolflows zijn geen zelfstandige datalaag en geen aparte module. Zij zijn een technische compositielaag over bestaande domeinmodules zoals Identity, Authorization, Catalog, Practice, Relationships, Communication, Support, LiveMonitoring, Admin, Reporting en Scheduling.

11.2 Scope en afbakening

Dit hoofdstuk beschrijft:

• de technische opbouw van rolgebonden routes, schermflows en service-aanroepen;
• de scheiding tussen UI-compositie en domeinlogica;
• de vaste server-side contextcontrole per rol;
• de belangrijkste leerling-, docent-, ouder-/voogd- en beheerderflows;
• de technische omgang met combinatierollen;
• het verschil tussen lege toestanden, fouttoestanden en autorisatieafwijzingen;
• hoe cross-module workflows binnen rolflows worden gecoördineerd.

Dit hoofdstuk beschrijft niet opnieuw:

• de volledige functionele scherminhoud;
• alle requirements en acceptatiecriteria;
• de databasekolommen per tabel;
• de volledige Blazor-componentstructuur;
• de detailuitwerking van individuele domeinmodules.

Voor die onderdelen gelden de betreffende Functioneel Ontwerp, Software Requirements Specification, schermdocumentatie, database-informatie en de betreffende hoofdstukken van het Technisch Ontwerp als bron.

11.3 Ontwerpuitgangspunten

Voor alle rolflows gelden de volgende technische uitgangspunten.

Uitgangspunt	Technische regel
Server-side context is leidend	De actieve gebruiker, accountstatus, rollen, relaties, autorisaties en objecttoegang worden server-side bepaald.
UI is nooit autorisatiebewijs	Routes, querystrings, browserstate, zichtbare knoppen, geselecteerde tabs of eerder geladen schermdata mogen toegang niet afdwingen.
Rolflows introduceren geen brondata	Brondata blijft eigendom van de domeinmodules. Rolflows combineren alleen bestaande modulefunctionaliteit.
Web bevat geen domeinlogica	OefenHub.Web composeert pagina’s en viewmodels via publieke modulecontracten.
Iedere command hercontroleert context	Starten, wijzigen, exporteren, live meekijken, accepteren, verwijderen of sluiten voert opnieuw server-side autorisatie uit.
Iedere query is gescoped	Query’s worden server-side beperkt tot de toegestane dataset voor de actuele rolcontext.
Leeg is niet hetzelfde als verboden	Geen resultaten, geen gekoppelde kinderen, geen online leerlingen of geen open meldingen zijn geldige lege toestanden.
Foutafhandeling lekt geen data	Toegangsfouten tonen geen objectnamen, kindnamen, runinhoud, antwoorden, tokens of technische payloads wanneer toegang ontbreekt.

11.4 Technische positie van rolflows

Rolflows worden technisch opgebouwd vanuit OefenHub.Web en publieke contracten van de modules. De route of pagina bepaalt alleen welke flow wordt gestart; de daadwerkelijke toegangscontrole ligt in Authorization en de domeinmodule die eigenaar is van het object.

Het diagram is een vereenvoudigde flowkaart. Het betekent niet dat Web directe toegang heeft tot DbContexts, entities of module-interne implementaties. Iedere pijl staat voor publieke contracts, query-services, command-services of page-composition-aanroepen.

11.5 Generiek flowpatroon

Iedere rolflow volgt hetzelfde technische basispatroon.

Stap	Technische verwerking
1. Route openen	OefenHub.Web ontvangt de route en laadt alleen minimale routeparameters.
2. Sessiecontext lezen	Identity- en Authorization-context worden server-side opgehaald.
3. Rolcontext bepalen	Authorization bepaalt of de gevraagde rolcontext beschikbaar is.
4. Objecttoegang controleren	De eigenaar-module valideert objecttoegang via publieke contracts.
5. Readmodel opbouwen	Query-services leveren alleen gescopete data terug.
6. UI tonen	Web toont viewmodels, acties en lege toestanden op basis van de server-side uitkomst.
7. Command uitvoeren	Bij iedere mutatie of export wordt stap 2 t/m 4 opnieuw uitgevoerd.
8. Logging/correlation	Iedere command, relevante query en foutafhandeling draagt dezelfde correlation-context.

11.6 Rolcontext en routecontext

De actieve rolcontext wordt niet afgeleid uit een URL-segment of browserselectie. Een route zoals /docent/... of /ouder/... kan alleen een gevraagde context aanduiden. De server bepaalt of die context daadwerkelijk geldig is.

Context	Technische bron
Ingelogde gebruiker	Externe identity provider plus intern Identity-account.
Account actief	Identity controleert interne accountstatus.
Beschikbare rollen	Authorization leest interne roltoekenningen.
Actieve rolcontext	Authorization bepaalt de actuele context volgens rolregels en gevraagde route.
Objecttoegang	Domeinmodule valideert toegang tot leerling, kind, run, ticket, relatie, bericht of beheerobject.

De rol Leerling is niet combineerbaar met ouder/voogd, docent of beheerder. Ouder/voogd, docent en beheerder kunnen wel gecombineerd voorkomen. Bij gecombineerde frontpages geldt de prioriteit beheerder, daarna docent, daarna ouder/voogd. Binnen specifieke routes blijft de gekozen rolcontext strikt gescheiden.

11.7 Leerlingflows

Leerlingflows draaien primair om oefenen, voortgang, resultaten, geschiedenis, gedeelde oefeningen, berichten, meldingen en profiel-/voorkeursinstellingen. De leerlingcontext wordt altijd server-side bepaald en gekoppeld aan het actieve niveau en de toegankelijke cataloguscontext.

11.7.1 Technische modules per leerlingflow

Flow	Primaire module	Belangrijke betrokken modules
Leerling-frontpage	Practice / Catalog	Authorization, Communication, Support
Oefenaanbod tonen	Catalog	Authorization, Practice
Oefening starten	Practice	Authorization, Catalog, ExerciseModuleHost
Oefening hervatten	Practice	Authorization, Catalog
Vraag beantwoorden	Practice	ExerciseModuleHost, LiveMonitoring
Resultaat tonen	Practice	ExerciseModuleHost, Reporting
Geschiedenis bekijken	Practice	Authorization, Reporting
PDF downloaden	Reporting	Practice, Authorization, ExerciseModuleHost
Oefening delen	Practice	Relationships, Communication, Authorization
Ontvangen gedeelde oefeningen	Practice	Relationships, Communication
Berichten	Communication	Authorization
Meldingen	Support	Communication, Authorization

11.7.2 Leerling-frontpage

De leerling-frontpage is een readmodelcompositie. Zij mag geen oefenruns, relaties, berichten of autorisaties wijzigen.

Technische regels:

• Web vraagt gescopete frontpagegegevens op via publieke query-services.
• Catalog levert alleen categorieën en oefeningen die binnen de actuele leerling-, niveau- en autorisatiecontext zichtbaar zijn.
• Practice levert recente oefeningen, populaire categorieën, statistiekblokken en eventueel een hervatbare run.
• Communication en Support leveren badges of actie-indicaties, maar de zichtbaarheid daarvan kan tijdens een actieve oefening worden onderdrukt.
• Tellerwaarden zijn readmodels en geen brondata.

11.7.3 Oefening starten

Bij het starten van een oefening wordt geen vertrouwen gesteld in de route, de zichtbare knop of het eerder geladen oefeningstartscherm.

De kritieke bronmutatie ligt in Practice: de nieuwe run, runcontext, snapshotvelden en initiële vraagpayload worden samen consistent opgeslagen. Communicatie- of badge-effecten zijn alleen onderdeel van dezelfde transaction boundary wanneer de specifieke workflow dat functioneel vereist.

11.7.4 Oefening beantwoorden

Na ieder bevestigd antwoord verwerkt Practice de vraagvoortgang server-side.

Technische regels:

• ExerciseModuleHost wordt gebruikt voor module-specifieke antwoordcontrole.
• Practice bewaart de uniforme voortgang, totalen en vraagstatus.
• LiveMonitoring ontvangt of leest voortgang als transport-/weergavegegeven, maar wijzigt de run niet.
• SignalR-updates zijn niet de bron van waarheid.
• De leerling-oefencontext onderdrukt afleidende badges, systeemnotificaties en actie-indicaties in de UI.

11.7.5 Resultaten, geschiedenis en PDF

Resultaatweergave, geschiedenis en PDF-export gebruiken dezelfde historische runbron.

Onderdeel	Technische bron
Samenvatting	Practice runvelden en snapshots.
Vraagdetails	Practice voortgang/payload.
Statistieken	opgeslagen uniforme statistiekvelden.
PDF-exportmodel	publiek contract van Practice.
PDF-rendering	Reporting met module-specifieke representatie via modulecontract.
Bestandsopslag	tijdelijke output, geen brondata.

11.8 Docentflows

Docentflows draaien om oefenaanbod, niveaus, categorieën, oefeningen, testflows, leerlingautorisaties, resultaten binnen docentcontext en live meekijken.

11.8.1 Technische modules per docentflow

Flow	Primaire module	Belangrijke betrokken modules
Docent-frontpage	Catalog / Practice	Authorization, Relationships, Support
Niveau beheren	Catalog	Authorization, Admin waar nodig
Categorie koppelen/aanmaken	Catalog	Authorization, Admin bij beheeractie
Oefening configureren	Catalog	ExerciseModuleHost, Modules.Abstractions
Testoefening starten	Practice	Catalog, ExerciseModuleHost
Leerlingenoverzicht	Relationships / Practice	Authorization
Niveauautorisaties beheren	Authorization / Catalog	Relationships, Communication
Geschiedenis bekijken	Practice	Authorization, Reporting
Online leerlingen	LiveMonitoring	Relationships, Practice, Authorization
Live meekijken	LiveMonitoring	Practice, Authorization

11.8.2 Oefenaanbod beheren

Catalog is eigenaar van de catalogusbrondata. Docentflows mogen catalogusobjecten alleen wijzigen via publieke cataloguscontracts.

Technische regels:

• De docentcontext wordt bij iedere beheeractie server-side gecontroleerd.
• Eigenaarschap, collaboratorstatus en niveaucontext worden door Catalog en Authorization beoordeeld.
• Moduleconfiguratie wordt gevalideerd via ExerciseModuleHost en het technische modulecontract.
• Oefeningmetadata en configuratiepayload blijven catalogusdata.
• Wijzigingen worden in catalogushistorie vastgelegd binnen het catalogusdomein.

11.8.3 Testoefeningen

Docenttestoefeningen mogen technisch gebruikmaken van Practice, maar worden als testcontext gemarkeerd.

Aspect	Technische regel
Persistente geschiedenis	Testoefeningen verschijnen niet in reguliere leerling-/docentgeschiedenis.
Runopslag	Tijdelijke runstructuur is toegestaan zolang IsTestRun of equivalente testmarkering aanwezig is.
Opruiming	Achtergebleven testdata wordt via Scheduling opgeruimd.
Autorisatie	Alleen docenten met geldige catalogus-/testcontext mogen een test starten.

11.8.4 Leerlingautorisaties

Docentautorisaties zijn geen losse UI-status, maar server-side autorisatiegegevens.

Technische regels:

• De leerling moet binnen een geldige docent-leerlingrelatie vallen.
• Bulk- en individuele mutaties gebruiken dezelfde server-side controles.
• Intrekken van niveauautorisatie wijzigt toekomstige toegang, maar herschrijft geen historische runs.
• Systeemcommunicatie aan leerlingen wordt via Communication verwerkt wanneer de workflow dat vereist.
• Systeemberichten kunnen kritiek zijn wanneer zij de enige bruikbare ingang of noodzakelijke terugkoppeling vormen.

11.8.5 Docentgeschiedenis en live meekijken

Docentgeschiedenis en live meekijken zijn strikt beperkt tot de eigen docentcontext.

Onderdeel	Technische grens
Geschiedenis	Alleen runs binnen de docentcontext en geautoriseerde niveaus.
Resultaatdetail	Run-ID is nooit voldoende; Practice en Authorization hercontroleren toegang.
PDF-export	Reporting gebruikt dezelfde autorisatiecontext als resultaatdetail.
Online-overzicht	LiveMonitoring toont alleen toegestane leerlingen.
Live meekijken	Alleen bij actieve run binnen docentautorisatie.

11.9 Ouder-/voogdflows

Ouder-/voogdflows zijn read-only ten opzichte van oefeningen, antwoorden, voortgang en resultaten. De actieve GuardianStudent-relatie is de primaire autorisatiebron.

11.9.1 Technische modules per ouder-/voogdflow

Flow	Primaire module	Belangrijke betrokken modules
Ouder-/voogd-frontpage	Practice / Relationships	Authorization, Communication, Support
Kinderenoverzicht	Relationships	Identity, Authorization
Kindinformatie	Relationships / Practice	Authorization
Resultatensamenvatting	Practice	Authorization, Relationships
Geschiedenis	Practice	Authorization, Reporting
Resultaatdetail	Practice	Authorization, Reporting
PDF-export	Reporting	Practice, Authorization
Online kinderen	LiveMonitoring	Relationships, Practice, Authorization
Live meekijken	LiveMonitoring	Practice, Authorization
Ontkoppelen	Relationships	Communication, Authorization

11.9.2 Kinderenoverzicht en kindinformatie

Technische regels:

• Alleen actieve ouder-/voogdrelaties worden getoond.
• Naamweergave en sortering zijn presentatievoorkeuren, geen autorisatiebron.
• Kindselectie is tijdelijke UI-context.
• Iedere vervolginzage herhaalt de server-side relatiecontrole.
• Ontbrekende kinderen is een geldige lege toestand.

11.9.3 Resultaten en geschiedenis

Ouder-/voogdinzage gebruikt dezelfde historische Practice-bron als leerling- en docentweergaven, maar met een andere autorisatiegrens.

Regel	Technische betekenis
Alle niveaus	Query’s worden begrensd door actieve ouder-/voogdrelatie, niet door docentautorisaties.
Alleen afgeronde runs	Niet-afgeronde runs verschijnen niet als historisch resultaat.
Geen mutaties	Ouder/voogd kan geen run starten, hervatten, beantwoorden, afronden, corrigeren of delen.
PDF-export	Export gebruikt dezelfde autorisatiecontrole als resultaatdetail.
Oude route	Oude RunId of browsergeschiedenis geeft geen toegang zonder actuele relatiecontrole.

11.9.4 Live meekijken

Ouder-/voogd-live-meekijken gebruikt LiveMonitoring en Practice, maar de autorisatiebron is de actieve ouder-/voogdrelatie.

Technische regels:

• Online-overzicht maakt nog geen LiveViewAudit aan.
• Bewuste live-start maakt wel een LiveViewAudit aan.
• De ouder/voogd kan door vragen bladeren, maar nooit antwoorden of voortgang wijzigen.
• Reconnect en beëindiging wijzigen de run van het kind niet.
• Bij beëindigde relatie vervalt nieuwe raadpleeg-, export- en live-toegang direct.

11.10 Beheerderflows

Beheerderflows draaien om site-instellingen, contentbeheer, accounts, rollen, categorieën, modules, docentondersteuning, systeemcommunicatie, meldingen en operationele beheerinzage. Beheerderflows geven geen reguliere live-meekijkfunctie op actieve leerlingruns.

11.10.1 Technische modules per beheerderflow

Flow	Primaire module	Belangrijke betrokken modules
Beheerder-frontpage	Admin	Support, Communication, Identity, Catalog
Site Instellingen-hub	Admin	Authorization
Frontpagebeheer en contentblokken	Admin	Web voor renderingcontext
Handige links, vaste pagina’s en footer	Admin	Web voor footer- en paginarendering
Popupbeheer	Admin	betrokken domeinen die popupkeys gebruiken
Systeemberichttemplates	Communication	Admin voor beheerroute en beheercontext
Features en systeemnotificaties	Admin	Web, Communication waar zichtbaarheid of signalering raakt
Technische systeeminstellingen	Admin	Infrastructure, Scheduling waar nodig
Accounts beheren	Identity / Authorization	Admin, Relationships
Rollen beheren	Authorization	Identity, Admin
Categoriebeheer	Catalog	Admin, Communication, Scheduling
Modulebeheer	Catalog / ExerciseModuleHost	Practice, Admin
Docentondersteuning	Admin als beheerroute	Catalog, Relationships, Practice, Authorization
Meldingenbeheer	Support	Communication, Relationships, Identity
Operationele jobs	Scheduling	betrokken domeinen

11.10.2 Beheerder-frontpage

De beheerder-frontpage is een read-only overzicht. Zij mag geen contextafhankelijke beheeractie uitvoeren zonder dat eerst een object is geselecteerd en de onderliggende module de actie autoriseert.

Technische regels:

• Admin levert beheerfrontpage-readmodels.
• Samenvattingen worden via module-eigen query-services opgebouwd.
• Tellers hebben expliciete scope en zijn geen brondata.
• Recente beheerwijzigingen komen uit domeinspecifieke history/logbronnen.

11.10.3 Site-instellingen en contentbeheer

Site Instellingen is technisch een hub naar onderliggende beheergebieden. De hub zelf voert geen mutatie uit, bewaart geen editorstate en geeft geen mutatierecht door aan doelpagina’s. Iedere doelpagina voert opnieuw server-side beheerautorisatie, objectvalidatie en historyregistratie uit.

Beheergebied	Technische eigenaar	Belangrijkste technische regel
Frontpagebeheer	Admin	Beheert tekstuele contentblokken per context. Layout, volgorde, componentstructuur en rendergedrag blijven codegedreven.
Handige links en vaste pagina’s	Admin	Beheert URL-records, vaste pagina-content, footercontent en footerplaatsingen. Interne en externe URL’s worden server-side gevalideerd.
Popupbeheer	Admin	Beheert bestaande popuprecords. Technische key, variant, theme, knopacties en custom renderer blijven read-only of codegedreven.
Systeemberichttemplates	Communication met beheerroute via Admin	Beheer wijzigt bestaande templates binnen validatiegrenzen. De templatebron wordt niet gedupliceerd in Admin.
Features	Admin	Beheert alleen expliciet togglebare functies. Verplichte kernfunctionaliteit wordt niet als featuretoggle ingericht.
Systeemnotificaties	Admin	Beheert planbare frontpage-overlays. Deze zijn gescheiden van mailbox-systeemberichten en popupregister-popups.
Technische systeeminstellingen	Admin	Wijzigt bestaande configuratiesleutels met datatype, invoervorm en validatie. Nieuwe sleutels ontstaan via code en migratie.

De beheerderinterface voor handige links en pagina’s werkt met herbruikbare URL-records, footerposities en contentblokken. Een URL-record dat nog in footerplaatsingen wordt gebruikt, mag niet hard worden verwijderd. Een wijziging in footercontent of vaste pagina-content mag geen navigatie- of autorisatieregel aanpassen.

11.10.4 Account- en rolbeheer

Accountbeheer en rolbeheer zijn gescheiden.

Onderdeel	Eigenaar
Intern account, status, provisioning, anonimisering	Identity
Rollen, roltoekenningen, contextresolving, policies	Authorization
Beheeractie, formulierflow en beheerlogging	Admin en eigenaar-module
Identity-providercredentials	Externe identity provider, niet OefenHub

Beheerdermutaties mogen geen wachtwoorden, providercredentials of externe identity-providerinterne data wijzigen.

11.10.5 Categorie- en modulebeheer

Categoriebeheer blijft catalogusdata. Beheerderflows kunnen categorie-identiteit wijzigen, migraties starten of modulemigraties orkestreren, maar de bronmutaties blijven bij Catalog en de technische modulevalidatie bij ExerciseModuleHost.

Technische regels:

• Migraties moeten expliciet, auditbaar en gemotiveerd zijn.
• Historische runs worden niet herschreven.
• Betrokken docenten kunnen via Communication geïnformeerd worden.
• Retrybare of zware migratieverwerking kan via Scheduling lopen.
• Cross-module hard FK’s worden niet geïntroduceerd om beheerflows eenvoudiger te maken.

11.10.6 Docentondersteuning

Docentondersteuning is een supportcontext boven bestaande docentstructuren. Zij maakt geen nieuwe centrale kopie van docentdata.

Technische regels:

• De beheerder selecteert een docentcontext.
• Authorization bepaalt of de beheerder de supportcontext mag openen.
• Catalog, Relationships en Practice blijven eigenaar van hun eigen data.
• Correcties worden via publieke modulecontracts uitgevoerd.
• Iedere correctie vereist logging/correlation en waar nodig een reden.

11.11 Combinatierollen

Combinatierollen worden niet opgelost door data of autorisaties samen te voegen. De gebruiker heeft meerdere mogelijke contexten, maar iedere route en iedere command gebruikt precies één actieve context.

Combinatie	Technische regel
Beheerder + docent	Beheerdercontext geeft geen impliciete docentresultaatinzage buiten support-/beheerflows.
Beheerder + ouder/voogd	Beheerdercontext vervangt geen ouder-/voogdrelatie voor ouderflows.
Docent + ouder/voogd	Docentroutes gebruiken docentautorisatie; ouderroutes gebruiken ouder-/voogdrelatie.
Leerling + andere rol	Niet toegestaan.

Frontpages mogen samenvattingsblokken combineren volgens de vastgelegde prioriteit, maar detailroutes blijven contextspecifiek.

11.12 Zichtbare acties versus toegestane acties

Een zichtbare knop betekent niet dat de actie zonder hercontrole uitgevoerd mag worden. Web gebruikt zichtbaarheid alleen voor gebruikerservaring.

UI-situatie	Server-side vereiste
Startknop oefening zichtbaar	Practice en Catalog hercontroleren starttoegang.
Geschiedenisregel klikbaar	Practice hercontroleert runtoegang.
PDF-knop zichtbaar	Reporting hercontroleert exporttoegang.
Live-knop actief	LiveMonitoring hercontroleert actuele livebeschikbaarheid.
Relatie-uitnodiging accepteerbaar	Relationships hercontroleert status, rolcontext en conflicten.
Ticketactie zichtbaar	Support hercontroleert ticketstatus en actorcontext.
Beheeractie zichtbaar	Eigenaar-module hercontroleert beheerrechten en objectstatus.

11.13 Lege toestanden, fouttoestanden en autorisatieafwijzingen

Rolflows moeten technisch onderscheid maken tussen lege toestanden en echte fouten.

Situatie	Technische behandeling
Geen gekoppelde kinderen	Lege ouder-/voogdtoestand.
Geen leerlingen online	Lege live-overzichtstoestand.
Geen afgeronde runs	Lege geschiedenis-/resultaattoestand.
Geen open meldingen	Lege meldingenlijst.
Ongeldige filterwaarde	Veilige filterfout of reset naar geldige filterbasis.
Object bestaat niet	Niet-beschikbaarafhandeling zonder datalek.
Object bestaat maar gebruiker heeft geen toegang	Toegang geweigerd zonder inhoudelijke details.
Account niet actief	Geen reguliere sessiecontext.
Rolcontext ontbreekt	Veilige redirect of context-geweigerdafhandeling.

11.14 Cross-module workflowgrenzen binnen rolflows

Rolflows kunnen meerdere modules raken. De functionele eigenaar van de gebruikersactie bepaalt de workflowgrens.

Workflow	Eigenaar	Kritieke stappen	Mogelijke naverwerking
Relatie-uitnodiging sturen	Relationships	uitnodiging en eventueel primaire systeemingang	badges, aanvullende notificaties
Gedeelde oefening aanmaken	Practice	shared record en toegangsvalidatie	systeemcommunicatie afhankelijk van gekozen ingang
Ticket doorzetten naar docent	Support	sluiting, doorzetregistratie, noodzakelijke communicatie	badges, readmodelverversing
Accountprovisioning	Identity	intern account en geldige toegangstoestand	uitnodigingskoppeling en systeemcommunicatie waar nodig
Categoriemigratie	Catalog	migratieregistratie en catalogusmutatie	docentcommunicatie, readmodelrebuilds

Een systeembericht is dus niet automatisch kritisch of niet-kritisch. De workflow bepaalt of het bericht onderdeel is van de functionele transactie, bijvoorbeeld wanneer het de primaire ingang voor een ontvanger is.

11.15 Logging en correlation binnen rolflows

Iedere rolflow draagt correlation-informatie door naar betrokken modules.

Minimale correlationgegevens:

Veld	Toepassing
CorrelationId	Verbindt request, workflow, domeinactie, job en foutafhandeling.
ActorUserId	Soft reference naar de uitvoerende gebruiker waar toegestaan.
ActorRoleContext	Snapshot van de actieve rolcontext.
TargetEntityType	Type object waarop de actie betrekking heeft.
TargetEntityId	Soft reference naar het object, zonder inhoudelijke payload in technische logs.
WorkflowName	Naam van de cross-module workflow of command.

Technische logs mogen geen wachtwoorden, tokens, antwoordpayloads, volledige berichteninhoud, volledige PDF-inhoud of onnodige persoonsgegevens bevatten.

11.16 Security- en privacygrenzen

Rolflows moeten voorkomen dat data via samengestelde schermen alsnog buiten de modulegrenzen lekt.

Technische regels:

• Page composition mag alleen gescopete query-services gebruiken.
• Viewmodels bevatten alleen velden die de actuele rolcontext mag zien.
• Browserstate bevat geen autorisaties, rolclaims, tokens of gevoelige domeindata.
• Popups en foutmeldingen tonen bij geweigerde toegang geen namen of inhoud van ontoegankelijke objecten.
• Snapshots met persoonsgegevens volgen het anonimiseringbeleid van de eigenaar-module.
• Exportflows gebruiken dezelfde autorisatiecontrole als de schermweergave.

11.17 Teststrategie voor rolflows

Rolflows worden niet alleen via end-to-endtests gevalideerd. Per laag wordt gericht getest.

Testtype	Doel
Authorization tests	Controleren dat contexten, rollen en objecttoegang correct worden afgewezen of toegestaan.
Module integration tests	Controleren dat eigenaar-modules hun commands en query’s correct scopen.
Cross-module workflowtests	Controleren dat kritieke stappen atomair zijn en naverwerking correct faalt/herstelt.
Web/page composition tests	Controleren dat viewmodels geen ongeautoriseerde data bevatten.
Architecture tests	Controleren dat Web geen DbContexts/entities gebruikt en modules alleen publieke contracts gebruiken.
Security regression tests	Controleren op IDOR, oude routecontext, filtermanipulatie en clientstate-misbruik.

11.18 Implementatiechecklist

Bij het implementeren of wijzigen van een rolflow moet minimaal worden gecontroleerd:

• is de functionele eigenaar van de flow duidelijk;
• welke rolcontext is vereist;
• welke module is eigenaar van de brondata;
• welke query-services worden gebruikt;
• welke commands zijn kritiek en moeten atomair zijn;
• welke vervolgacties zijn retrybaar of beheerbaar falend;
• welke lege toestanden moeten veilig getoond worden;
• welke fouttoestanden mogen geen data lekken;
• welke readmodels of badges worden geraakt;
• welke logging/correlationgegevens nodig zijn;
• welke impact op Functioneel Ontwerp, Software Requirements Specification, Technisch Ontwerp en database-informatie de wijziging heeft;
• welke tests of architecture checks moeten worden uitgebreid.

11.19 Implementatieverificaties

De volgende punten moeten bij implementatie of toekomstige detailuitwerking van het Technisch Ontwerp concreet worden gemaakt:

Onderwerp	Verificatiepunt
Routeconventies	Definitieve URL- en routeprefixen per rolcontext vastleggen in Web.
Page composition	Bepalen welke frontpages en dashboards aparte page-composition services krijgen.
Workflowcatalogus	Per cross-module workflow vastleggen welke stappen kritiek, retrybaar of beheerbaar falend zijn.
Contextswitch UI	Bepalen hoe gebruikers met combinatierollen contextselectie en frontpageblokken zien.
Access-denied UX	Uniforme fout- en redirectpatronen afstemmen met popupregister en schermdocumentatie.
Testdekking	Rolflowtests koppelen aan Software Requirements Specification/acceptatiecriteria en architecture tests.
Loggingvelden	Definitieve technische veldnamen voor correlation en actorcontext afstemmen met logginghoofdstuk.