3. Domeinkaart
Deze kaart verbindt het ERD-hoofdstuk aan de bestaande databasehoofdstukken. De aantallen zijn gebaseerd op de huidige Markdownstructuur en zijn bedoeld als oriëntatie, niet als formele telling voor implementatie.
| ERD-pagina | Brondocument | Tabellen | FK-velden |
|---|---|---|---|
| Identiteit en autorisatie | 01_identiteit-en-autorisatie.md | 5 | 7 |
| Relatiebeheer | 02_relatiebeheer.md | 4 | 20 |
| Docentstructuur en leerlingtoegang | 03_docentstructuur-en-leerlingtoegang.md | 12 | 34 |
| Communicatie en notificaties | 04_communicatie-en-notificaties.md | 5 | 11 |
| Configuratie en contentbeheer | 05_configuratie-en-contentbeheer.md | 17 | 34 |
| Ticket- en meldingsbeheer | 06_ticket-en-meldingsbeheer.md | 11 | 28 |
| Oefenruns, delen en voortgang | 07_oefenruns-delen-en-voortgang.md | 3 | 13 |
| Audit, historie en technische uitgangspunten | 08_audit-historie-en-technische-uitgangspunten.md | n.v.t. | n.v.t. |
3.1 Gebruik
- Begin bij een domeinpagina wanneer je functioneel wilt begrijpen welke tabellen bij elkaar horen.
- Gebruik de relatie-index wanneer je een specifieke FK of verwijzing wilt controleren.
- Gebruik cross-domein relaties wanneer de vraag domeinen overstijgt, bijvoorbeeld
Users,ExerciseRuns,SystemMessages,Ticketsof configuratiebronnen zoalsSystemMessageTemplatesenSiteNotifications.
3.2 Startpunten per vraagtype
| Ik zoek naar... | Begin bij | Waarom |
|---|---|---|
| Rollen, profiel, instellingen of Keycloak-koppeling | Identiteit en autorisatie | Users, Roles, UserRoles en UserSettings bepalen de basiscontext. |
| Vrienden, ouder-/voogdrelaties, docentrelaties of uitnodigingen | Relatiebeheer | UserRelationships en RelationshipInvitations zijn de bron voor formele koppelingen tussen accounts. |
| Niveaus, categorieën, oefeningen, modules of leerlingtoegang | Docentstructuur en leerlingtoegang | Dit domein bepaalt de onderwijsstructuur waarbinnen oefenruns ontstaan. |
| Resultaten, voortgang, geschiedenis, PDF of gedeelde oefeningen | Oefenruns, delen en voortgang | ExerciseRuns is de historische bron; ExerciseRunProgress en SharedExercises vullen de details aan. |
| Systeemberichten, privéberichten, mailboxbadges of thread-events | Communicatie en notificaties | SystemMessages en privéthreads blijven gescheiden bronnen, maar worden gecombineerd in mailboxreadmodels. |
| Meldingen, oplossingen, heropenen, behandeling door beheer of doorzetten naar docent | Ticket- en meldingsbeheer | Tickets is het hoofdrecord; assignments, discussie, closures, reopen requests, snapshots en doorzetrecords vormen de lifecycle eromheen. |
| Beheerbare content, footer, popups, templates, features of sitebrede systeemnotificaties | Configuratie en contentbeheer | Dit domein bevat beheerbare brondata voor pagina-inhoud, feedback, templates, overlays en sitebreed gedrag. |
| Audit, snapshots, JSON/base64 of bewuste niet-FK's | Audit, historie en technische uitgangspunten | Deze pagina verzamelt patroonkeuzes die in meerdere domeinen terugkomen. |
3.3 Inzoomvolgorde
Voor review is deze volgorde meestal het meest logisch:
- Identiteit en autorisatie: wie bestaat er en welke rolcontexten zijn mogelijk?
- Relatiebeheer: welke gebruikers mogen functioneel iets met elkaar?
- Docentstructuur en leerlingtoegang: welke onderwijscontext en autorisaties bestaan er?
- Oefenruns, delen en voortgang: wat gebeurt er wanneer een leerling daadwerkelijk oefent?
- Communicatie en notificaties: hoe worden gebruikers geïnformeerd via systeemberichten, privéthreads, thread-events en badges?
- Ticket- en meldingsbeheer: hoe gebruiken meldingen dezelfde communicatiepatronen voor updates, discussie, sluiting, heropenen en doorzetten naar docent?
- Configuratie en contentbeheer: welke templates, popups, sitebrede notificaties, featuretoggles en beheerbare content ondersteunen de applicatie?
- Audit, historie en uitzonderingen: welke patronen gelden over alle domeinen heen?
Deze volgorde voorkomt dat je vanuit een resultaat, bericht, ticket of beheerwaarde naar een nog onbekende broncontext moet terugredeneren.
3.4 Communicatie versus configuratie
De naam Communicatie en notificaties kan verwarrend zijn omdat niet alle communicatie-gerelateerde tabellen in hetzelfde databasehoofdstuk staan. Gebruik daarom deze scheiding:
| Onderdeel | Primair ERD-domein | Waarom |
|---|---|---|
| Mailbox-systeemberichten | Communicatie en notificaties | Runtime berichten per ontvanger via SystemMessages. |
| Privéberichtthreads | Communicatie en notificaties | Conversaties, deelnemers, berichten, readstate en thread-events. |
| Systeemberichttemplates | Configuratie en contentbeheer | Beheerbare sjablooninhoud; geen verzonden mailboxrecord. |
| Sitebrede systeemnotificaties | Configuratie en contentbeheer | Frontpage-overlay op basis van doelgroep, start/eindmoment en displayregel. |
| Popupteksten | Configuratie en contentbeheer | Beheerbare feedbacktekst; geen bericht en geen mailboxitem. |
Voor review betekent dit: lees eerst de communicatiepagina voor runtime mailboxgedrag en lees daarna configuratie/contentbeheer wanneer je wilt begrijpen hoe templates, popups of sitebrede notificaties beheerd worden.
3.5 Verdiept startpunt voor tickets
Voor ticketvragen is het nuttig om niet alleen naar de FK's te kijken, maar eerst te bepalen welke laag je bedoelt.
| Vraag | Ticketlaag | Primaire tabel |
|---|---|---|
| Wat is de actuele status van de melding? | Actuele toestand | Tickets |
| Wie behandelt of behandelde de melding? | Behandelcontext | TicketAssignments |
| Wat is inhoudelijk besproken? | Discussie | TicketDiscussionMessages |
| Welke auditacties zijn uitgevoerd? | Compacte audit | TicketHistory |
| Wat was de formele oplossing of sluitreden? | Sluitbron | TicketClosures |
| Waarom is de melding opnieuw geopend? | Heropenbron | TicketReopenRequests |
| Waarom is de melding naar een docent doorgezet? | Doorzetregistratie | TicketForwardedToTeacher |
| Welke technische context gold bij melden? | Snapshot | TicketTechnicalSnapshots |
Deze laagindeling voorkomt dat discussie, audit, oplossingstekst en technische context in één onoverzichtelijk diagram worden samengevoegd.
3.6 Verdiept startpunt voor configuratie en contentbeheer
Voor configuratievragen is vooral belangrijk of je kijkt naar beheerbare brondata, history, of het runtime-effect van die brondata.
| Vraag | Configuratielaag | Primaire tabel(len) |
|---|---|---|
| Welke functies staan sitebreed aan of uit? | Featurebeschikbaarheid | SiteFeatureToggles, SiteFeatureToggleHistory |
| Welke globale niet-booleaanse waarde gebruikt de applicatie? | Systeeminstelling | SystemSettings |
| Welke tekst staat op frontpages, vaste pagina's of in de footer? | Beheerbare content | ContentBlocks, ContentBlockHistory |
| Welke URL's en footerkolommen worden getoond? | Footer en links | SiteLinks, FooterSections, FooterLinkAssignments |
| Welke popuptekst of knoplabels horen bij een bekende popupkey? | Popupregister | PopupDetails, PopupDetailsHistory, PopupDetailsHistoryItems |
| Welke tekst gebruikt systeemcommunicatie als sjabloon? | Templatebeheer | SystemMessageTemplates, SystemMessageTemplateHistory |
| Welke tijdelijke overlay moet na frontpageload verschijnen? | Sitebrede notificatie | SiteNotifications, SiteNotificationHistory |
| Wie heeft een beheerwaarde gewijzigd? | History en actorcontext | De bijbehorende *History-tabel plus Users-actorvelden |
Deze indeling voorkomt dat configuratiebronnen worden verward met runtime-objecten. Een template is geen bericht, een popupdefinitie is geen ticketfeedbackrecord, en een sitebrede notificatie is geen mailboxitem.
3.7 Verdiept startpunt voor audit, historie en technische uitgangspunten
De auditpagina is geen gewone tabelgroep, maar een controlelaag over alle eerdere domeinen. Start daar wanneer je twijfelt of een relatie hard, logisch, historisch of afgeleid is.
| Vraag | Auditlaag | Voorbeelden |
|---|---|---|
| Wie heeft iets gewijzigd? | Actor-audit | ChangedByUserId, CreatedByUserId, ClosedByUserId |
| Welke wijzigingen zijn reconstructeerbaar? | Append-only history | CategoryHistory, ExerciseHistory, RelationshipEvents, TicketHistory, *History-tabellen |
| Welke lifecycle-stap heeft een eigen bronrecord? | Formele lifecycle-bron | TicketClosures, TicketReopenRequests, TicketAssignments, TicketForwardedToTeacher |
| Welke waarde moet historisch leesbaar blijven? | Snapshot | ViewerRoleNameSnapshot, technische ticketsnapshot, gedeelde-oefening-context |
| Welke verwijzing is bewust geen FK? | Logische verwijzing | SystemMessages.EntityType + EntityId, FeatureKey, SettingKey |
| Welke data blijft modulespecifiek? | Payload | JSON/base64-configuratie en vraag-/antwoordpayloads |
| Welke waarde is alleen een overzicht? | Readmodel | badges, frontpagetellers, ouder-/voogdresultaatreadmodels |
3.8 Domeinen en relatiepatronen
Voor review is niet alleen het domein belangrijk, maar ook het type relatie dat je verwacht te vinden. Gebruik daarom deze snelle route:
| Je zoekt naar | Gebruik eerst | Controleer daarna |
|---|---|---|
| Een harde FK tussen twee tabellen | Relevante domeinpagina | Relatie-index |
| Een verwijzing vanuit een systeembericht | Communicatie en notificaties | Cross-domein relaties |
| Historische leesbaarheid na mutatie | Audit, historie en technische uitgangspunten | Relevante domeinpagina |
| Resultaat- of geschiedenisbron | Oefenruns, delen en voortgang | Docentstructuur en leerlingtoegang |
| Autorisatie of zichtbaarheid | Identiteit en autorisatie of Relatiebeheer | De functionele domeinpagina waar de actie plaatsvindt |