14. Zoompad en onderhoud

Deze pagina bewaakt het onderhoud en de doorlopende validatie van het ERD-hoofdstuk. Eerdere open punten zijn omgezet naar V1.0-keuzes of onderhoudscontroles, zodat het ERD bruikbaar blijft voor review en implementatievalidatie.

14.1 Voorgesteld zoompad

Stap	Focus	Status	Resultaat
1	Structuur en navigatie	Gereed	Deze map, domeinpagina's, helikopterbeeld en relatie-index.
2	Identiteit, rollen en relaties	Gereed	Uitgewerkt deel-ERD voor Users, Roles, UserRoles, UserRelationships en uitnodigingen.
3	Docentstructuur en oefencatalogus	Gereed	Deel-ERD voor niveaus, categorieën, oefeningen, modules, collaborators en autorisaties.
4	Oefenruns en resultaten	Gereed in eerste diepte	Deel-ERD voor runs, progress, gedeelde oefeningen, duplicaten, historie en PDF-bronnen.
5	Communicatie en notificaties	Gereed in eerste diepte	Deel-ERD voor SystemMessages, privéthreads, mailbox-readmodels, thread-events en logische domeinverwijzingen.
6	Ticket- en meldingsbeheer	Gereed in eerste diepte	Deel-ERD voor tickets, behandelcontext, discussie, history, closures, reopen requests, technische snapshots en doorzetten naar docent.
7	Contentbeheer en beheerinstellingen	Gereed in eerste diepte	Deel-ERD voor contentblokken, popups, templates, features, notificaties, footer, URL's, runtime-effecten en history.
8	Audit, snapshots en uitzonderingen	Gereed in eerste diepte	Overzicht van historytabellen, FK+snapshot, logische verwijzingen, snapshots, payloads, readmodels en bewuste niet-FK's.
9	Consolidatie en kwaliteitscontrole	Gereed	Terminologie, linkstijl, navigatie, relatie-indexinterpretatie en onderhoudspunten gelijkgetrokken over de ERD-set.

14.2 Criteria voor opsplitsen naar extra subpagina's

Maak een extra onderliggende pagina wanneer een domeindiagram:

• meer dan ongeveer 12 tot 15 tabellen bevat;
• meer dan ongeveer 20 tot 25 relaties bevat;
• meerdere functionele subdomeinen door elkaar toont;
• veel cross-domein lijnen bevat waardoor de kernrelaties niet meer zichtbaar zijn.

14.3 Lessen uit ronde 4: oefenruns

Voor Oefenruns, delen en voortgang bleek het aantal tabellen klein, maar de functionele afhankelijkheid groot. Daarom is de pagina niet opgesplitst in extra subpagina's, maar wel verrijkt met drie verschillende diagramtypen:

• een intern kern-ERD voor ExerciseRuns, ExerciseRunProgress en SharedExercises;
• een context-ERD met de belangrijkste externe tabellen;
• flowdiagrammen voor run-lifecycle en gedeelde-oefening-lifecycle.

Dit patroon is ook bruikbaar voor andere domeinen die relatief weinig tabellen hebben maar veel functionele gedragspaden kennen.

14.4 Lessen uit ronde 5: communicatie

Voor Communicatie en notificaties bleek vooral de scheiding tussen harde FK's en logische verwijzingen belangrijk. De pagina is daarom verrijkt met meerdere diagramtypen:

• een intern kern-ERD voor privéberichtthreads, deelnemers, berichten en thread-events;
• een minimaal ERD voor SystemMessages met alleen de harde ontvanger-FK;
• een flowchart voor EntityType + EntityId, omdat dit bewust geen harde database-FK is;
• lifecycle-diagrammen voor nieuwe privéberichten, antwoorden en systeemberichten;
• een contextdiagram voor templates, popups en sitebrede notificaties die in configuratie/contentbeheer staan.

Dit patroon is bruikbaar voor andere domeinen waar het logisch model meer zegt dan een puur relationeel diagram.

14.5 Lessen uit ronde 6: tickets

Voor Ticket- en meldingsbeheer bleek de belangrijkste keuze dat de pagina niet alleen als ERD gelezen moet worden, maar als lifecycle rond Tickets. Daarom zijn meerdere diagramtypen toegevoegd:

• een intern kern-ERD voor Tickets, lookups, assignments, discussie, history, closures, reopen requests, doorzetten en snapshots;
• een actor- en communicatiecontextdiagram voor alle Users-relaties en de koppeling naar reguliere privéberichten;
• een expliciete flowchart voor SystemMessages.EntityType = Ticket, omdat dit een logische verwijzing blijft;
• lifecycle-diagrammen voor behandelen, wachten op gebruiker, oplossen/sluiten, heropenen en periodiek verlopen van heropentermijnen;
• een aparte doorzet-naar-docentflow, omdat die zowel het ticketdomein als het privéberichtdomein raakt.

Het vaste patroon blijft: actuele samenvatting op het hoofdrecord, formele brondata in gespecialiseerde subtabellen, en cross-domein effecten expliciet maar niet als onbedoelde harde FK tekenen.

14.6 Lessen uit ronde 7: configuratie en contentbeheer

Voor Configuratie en contentbeheer bleek vooral het onderscheid tussen beheerbare brondata en runtime-objecten belangrijk. De pagina is daarom niet alleen als tabelcluster uitgewerkt, maar als ondersteunend brondomein voor applicatiegedrag.

Toegevoegd zijn:

• een intern kern-ERD voor popups, contentblokken, links/footer, templates, site-notificaties en featuretoggle-history;
• een actorcontextdiagram dat laat zien dat Users hier vooral beheerder, wijzigingsactor of soft-deleteactor is;
• flowdiagrammen voor contentblokwijziging, footerlinkplaatsing, systeemnotificatie-weergave, featuretoggle-/settingwijziging en templategebruik;
• een expliciete scheiding tussen SystemMessageTemplates als configuratiebron en SystemMessages als runtime mailboxrecord;
• een overzicht van bewuste niet-FK's zoals FeatureKey, SettingKey, DomainType, ContextType, DisplayRule, ButtonTheme en custom renderer/action keys.

Het vaste patroon voor dit domein is: actuele configuratie in de brontabel, veldniveau-history in de bijbehorende historytabel, en runtime-effecten via applicatielogica in plaats van ongewenste harde FK's.

14.7 Lessen uit ronde 8: audit, historie en technische uitgangspunten

Voor Audit, historie en technische uitgangspunten bleek dat dit geen klassiek tabeldomein is, maar een validatielaag over alle eerdere ERD-pagina's heen. De pagina is daarom uitgewerkt als patrooncatalogus in plaats van als één groot audit-ERD.

Toegevoegd zijn:

• een overkoepelend patroon voor bronrecords, history, actorvelden, snapshots, enumwaarden, payloads, readmodels en technische logging;
• representatieve ERD's voor actor-audit, ticket-lifecycle, live meekijken en relatie-events;
• een expliciete flowchart voor logische verwijzingen zoals SystemMessages.EntityType + EntityId;
• een snapshotmatrix voor historische leesbaarheid;
• uitleg over JSON/base64-payloads, readmodels, badges, scheduler/cleanup en retentie;
• een checklist waarmee toekomstige ERD-wijzigingen consequent kunnen worden beoordeeld.

Het vaste patroon voor toekomstige rondes is nu: teken harde FK's als ERD, teken logische verwijzingen als context/flow, benoem snapshots expliciet, en behandel readmodels niet als brondata zolang geen fysieke tabel is gedefinieerd.

14.8 Afgedichte ERD-keuzes en resterend onderhoud

De eerdere open punten zijn na de DB/ERD-cleanup niet langer baseline-blokkers. Waar een keuze nodig was, is deze hieronder vastgelegd. Wat overblijft is onderhoud bij implementatie, Docusaurus-rendering of latere datamodelwijzigingen.

Onderwerp	V1.0-keuze	Resterend onderhoud
Diagramtechniek	Mermaid blijft de standaard voor deel-ERD's, flowcharts en contextdiagrammen. Statische SVG/PNG mag alleen aanvullend worden gebruikt wanneer Mermaid in Docusaurus aantoonbaar te breed of onleesbaar wordt.	Visuele Docusaurus-rendering controleren na grotere diagramwijzigingen.
Relatie-index	De relatie-index wordt handmatig onderhouden als documentatiebron en periodiek gevalideerd tegen EF/migrations. Automatische generatie is geen V1.0-baseline.	Bij nieuwe tabellen/relaties relatie-index en brondatabasehoofdstuk samen aanpassen.
Logische verwijzingen zonder harde FK	Per domein worden alleen functioneel belangrijke soft links, snapshots en polymorfe verwijzingen getoond. Harde FK's blijven herkenbaar gescheiden van soft links.	Nieuwe logische verwijzingen langs de checklist in audit, historie en technische uitgangspunten leggen.
Polymorfe verwijzingen	EntityType + EntityId-achtige patronen worden als flow/contextdiagram en tekstuele relatie-inventaris gemodelleerd, niet als harde ERD-relatie.	Bij nieuwe polymorfe patronen dezelfde notatie gebruiken.
ERD-sidebar	Sidebarplaatsing is navigatieconfiguratie. De ERD-inhoud blijft toegankelijk via ERD-intro en de handmatige sidebar kan deze volgorde volgen.	Alleen aanpassen wanneer de documentatiestructuur wijzigt.
Historische FK versus actuele beheer-FK	Geen extra lijnstijl naast harde lijn, stippellijn en relatietype-label. Het onderscheid wordt in relatie-inventaris en toelichting benoemd.	Nieuwe relatiepatronen eerst in de relatie-index classificeren.
Gedeelde oefeningen	De dubbele richting SharedExercises.StartedExerciseRunId en ExerciseRuns.SharedExerciseId blijft bewust behouden in de V1.0-baseline.	Alleen herzien op basis van implementatie-/migratiebewijs.
Mailbox-readmodel	Geen aparte fysieke mailboxtabel in database-informatie zolang geen duurzame tabel of SQL-view wordt ontworpen. Query-/materialisatiekeuzes blijven bij het Technisch Ontwerp/readmodeluitwerking.	Database-informatie uitbreiden wanneer een fysiek readmodel wordt geïntroduceerd.

14.9 Status na DB/ERD-cleanup

De ERD-set bevat na deze cleanup geen open baselinepunten meer. De eerdere open punten zijn omgezet naar expliciete V1.0-keuzes of naar onderhoudscontroles. De belangrijkste blijvende controles zijn:

• technische validatie tegen EF-modellen, migrations en databaseconstraints;
• inhoudelijke correcties wanneer de brondatabasehoofdstukken wijzigen;
• visuele Docusaurus-rendering controleren na grotere Mermaid-wijzigingen;
• uitbreiding van detailpagina's voor modulepayloads, fysieke readmodels of query-/viewdocumentatie wanneer die later daadwerkelijk worden ontworpen.

14.10 Doorlopende validatie

Prioriteit	Controle	Waarom belangrijk
Hoog	Vergelijk de relatie-index met EF/migrations.	Voorkomt dat diagrammen en brondatabase uit elkaar lopen.
Hoog	Bevestig alle logische verwijzingen zonder harde FK, vooral SystemMessages.EntityType + EntityId.	Voorkomt dat later per ongeluk polymorfe FK's worden gesuggereerd.
Hoog	Controleer FK + snapshot-patronen bij live meekijken, gedeelde oefeningen en tickets.	Historische leesbaarheid hangt af van correcte snapshotvelden.
Midden	Splits diagrammen verder op wanneer Mermaid-weergave te breed of onleesbaar wordt.	Houdt Docusaurus-pagina's bruikbaar.
Midden	Voeg eventueel detailpagina's toe voor modulepayloads en readmodels.	Voorkomt dat relationele ERD's worden vervuild met JSON-/UI-details.