Open punten, ontwerpbesluiten en Technisch Ontwerp-besluitenregister

26.1 Doel van dit hoofdstuk

Dit hoofdstuk bundelt de belangrijkste technische ontwerpbesluiten, implementatieverificaties en aandachtspunten voor de V1.0-baseline van het Technisch Ontwerp. De inhoudelijke uitwerking staat in de betreffende hoofdstukken; dit hoofdstuk bewaakt dat de gemaakte keuzes traceerbaar blijven en dat resterende verificaties niet verspreid raken over losse tekstpassages.

Het aanvullende register to-open-punten-en-besluiten bevat de praktische detailregistratie van besluiten en aandachtspunten. Dit hoofdstuk is de samenvattende baseline-laag. Wanneer een detailpunt definitief wordt opgelost, hoort de uitkomst in het relevante inhoudelijke hoofdstuk of in de bron waar de wijziging thuishoort.

26.2 Afbakening

Dit hoofdstuk introduceert geen nieuwe functionele requirements. Wanneer een aandachtspunt leidt tot een nieuwe of gewijzigde functionele regel, moet die wijziging worden verwerkt in het Functioneel Ontwerp, de Software Requirements Specification, de schermdocumentatie, usecases of database-informatie voordat zij als technische implementatiekeuze wordt toegepast.

Onderwerp	Hoort hier thuis?	Toelichting
Technisch ontwerpbesluit	Ja	Bijvoorbeeld keuze voor modulegrenzen, DbContexts, schema's, loggingpatronen of retrybeleid.
Implementatieverificatie	Ja	Bijvoorbeeld controle op TickerQ-configuratie, Content Security Policy of EF Core migration history.
Operationeel aandachtspunt	Ja	Bijvoorbeeld backup/restore, monitoring, deployment of incidentafhandeling.
Nieuwe functionele eis	Nee	Hoort in Functioneel Ontwerp en Software Requirements Specification en daarna pas in het Technisch Ontwerp.
Volledige tabeldefinitie	Nee	Database-informatie blijft bron voor tabeldetails, kolommen, enumwaarden en relationele broninformatie.
Story-specifieke implementatietaak	Alleen samengevat	Detailtaken horen in issue- of storyregistratie; dit hoofdstuk bewaakt alleen ontwerpimpact.

26.3 Statuswaarden

Status	Betekenis
Vastgelegd	De keuze is onderdeel van de V1.0-baseline van het Technisch Ontwerp.
Implementatieverificatie	De ontwerprichting is vastgesteld, maar concrete technische configuratie of tooling moet vóór implementatie aantoonbaar worden gevalideerd.
Buiten huidige baseline	Het onderwerp is bewust niet nodig voor de V1.0-baseline en vereist een nieuw ontwerpbesluit voordat het wordt toegevoegd.
Vervallen	Het punt is bewust niet meer van toepassing.
Escaleren naar Functioneel Ontwerp, Software Requirements Specification of database-informatie	Het punt raakt functionele regels, requirements of datamodelbroninformatie en hoort niet uitsluitend in het Technisch Ontwerp te worden opgelost.

26.4 Vastgelegde ontwerpbesluiten

ID	Besluit	Status	Primaire verwijzing binnen het Technisch Ontwerp
TO-BES-001	OefenHub wordt uitgewerkt als middel-zware modulaire monoliet: één deploybare applicatie met expliciete modulegrenzen.	Vastgelegd	Hoofdstuk 01, 02, 03
TO-BES-002	De eerste technische baseline gebruikt één relationele database en één applicatieconnectionstring.	Vastgelegd	Hoofdstuk 02, 07, 20
TO-BES-003	Eén domeinproject heeft maximaal één eigen DbContext en daarmee één primair databaseschema.	Vastgelegd	Hoofdstuk 02, 06, 07
TO-BES-004	Databaseschema's worden in kleine letters geschreven; tabellen en kolommen gebruiken PascalCase.	Vastgelegd	Hoofdstuk 02, 07
TO-BES-005	Er komen in de basis geen aparte projecten OefenHub.Audit, OefenHub.Security, OefenHub.Workflows of OefenHub.ReadModels.	Vastgelegd	Hoofdstuk 02, 06, 19, 20
TO-BES-006	Audit en history worden primair domeinspecifiek opgeslagen naast de brondata van het domein.	Vastgelegd	Hoofdstuk 06, 14, 19, 25
TO-BES-007	Security wordt volledig beschreven, maar verdeeld over Web, Infrastructure, Identity, Authorization, Scheduling en domeinmodules.	Vastgelegd	Hoofdstuk 19, 20
TO-BES-008	OefenHub.Practice is de module voor oefenruns, voortgang, resultaten, gedeelde oefeningen en PDF-brondata.	Vastgelegd	Hoofdstuk 02, 10
TO-BES-009	Module-implementaties zijn standaard internal; alleen publieke contracten in Contracts zijn bedoeld voor gebruik door andere modules.	Vastgelegd	Hoofdstuk 03
TO-BES-010	OefenHub.Web bevat UI-compositie, routing en viewmodels, maar geen domeinlogica, DbContexts of module-interne entities.	Vastgelegd	Hoofdstuk 03, 24
TO-BES-011	Cross-module verwijzingen zijn standaard soft links of soft links met snapshot; harde foreign keys over modulegrenzen zijn uitzondering.	Vastgelegd	Hoofdstuk 06, 07
TO-BES-012	Foreign key + snapshot wordt primair binnen hetzelfde domein toegepast; over modulegrenzen geldt soft link + snapshot als standaardpatroon.	Vastgelegd	Hoofdstuk 07, 25
TO-BES-013	Per cross-module workflow wordt expliciet bepaald welke stappen onderdeel zijn van de functionele transactie.	Vastgelegd	Hoofdstuk 03, 07, 12, 14, 18
TO-BES-014	Een systeembericht kan kritiek of retrybaar zijn afhankelijk van de functionele rol binnen de workflow.	Vastgelegd	Hoofdstuk 12, 13, 14, 18
TO-BES-015	OefenHub.Scheduling is eigenaar van de technische joblifecycle zodra een job succesvol is aangemaakt.	Vastgelegd	Hoofdstuk 18, 21
TO-BES-016	Domeinmodules blijven eigenaar van de domeinlogica die door jobs wordt uitgevoerd.	Vastgelegd	Hoofdstuk 18
TO-BES-017	TickerQ wordt gebruikt voor periodieke en uitgestelde verwerking; er komt geen RabbitMQ of externe message broker in de eerste baseline.	Vastgelegd	Hoofdstuk 18, 21
TO-BES-018	Module-eigen readmodels staan onder Models/ReadModels; er komt geen centraal ReadModels-project in de basis.	Vastgelegd	Hoofdstuk 03, 17
TO-BES-019	Concrete oefenmodules gebruiken de naamvorm OefenHub.Modules.<ModuleCategory>.<ModuleName>.	Vastgelegd	Hoofdstuk 02, 09
TO-BES-020	Concrete oefenmodules gebruiken OefenHub.Modules.Abstractions als primaire afhankelijkheid.	Vastgelegd	Hoofdstuk 09
TO-BES-021	Gebruik van OefenHub.SharedKernel door concrete oefenmodules is toegestaan wanneer dit aantoonbaar generieke duplicatie voorkomt.	Vastgelegd	Hoofdstuk 03, 09
TO-BES-022	PDF-bestanden zijn tijdelijke output; Practice blijft bron van run- en resultaatdata.	Vastgelegd	Hoofdstuk 10, 16, 25
TO-BES-023	SignalR is transport voor realtime updates; Practice blijft bron van oefenvoortgang.	Vastgelegd	Hoofdstuk 10, 15
TO-BES-024	Testprojecten worden per module georganiseerd onder een solution folder of fysieke map tests.	Vastgelegd	Hoofdstuk 02, 03, 23
TO-BES-025	Architecture tests bewaken dependencyregels aanvullend op internal en projectreferences.	Vastgelegd	Hoofdstuk 03, 23
TO-BES-026	Seeddata is module-eigen, idempotent en mag beheerbare content niet ongemerkt overschrijven.	Vastgelegd	Hoofdstuk 07, 08, 13, 20
TO-BES-027	Iedere relevante technische flow draagt een correlation-id door voor logging, jobs en cross-module herleidbaarheid.	Vastgelegd	Hoofdstuk 18, 19, 21
TO-BES-028	Fallbackgedrag mag autorisatie, privacy, brondata of historische reconstructie nooit omzeilen.	Vastgelegd	Hoofdstuk 22, 25
TO-BES-029	Accountanonimisering gebruikt vaste waarden: FirstName = Anoniem, MiddleName = #, LastName = <niet-voorspelbare systeemcode> en Email = anoniem.<code>@verwijderd.acc.	Vastgelegd	Hoofdstuk 25
TO-BES-030	Serilog met Seq is de loggingbaseline voor gestructureerde technische logging en centrale loganalyse.	Vastgelegd	Hoofdstuk 19, 21
TO-BES-031	Aspire wordt alleen gebruikt als development-only ondersteuning voor configuratie-, dependency- en secrets-pariteit.	Vastgelegd	Hoofdstuk 20
TO-BES-032	OefenHub heeft in de eerste baseline geen publieke functionele API-laag voor externe clients of mobiele apps; desktop en tablet zijn leidend.	Vastgelegd	Hoofdstuk 02, 22, 24
TO-BES-033	MudBlazor is de primaire componentenbibliotheek voor de interactieve Blazor Web UI, toegepast via een eigen OefenHub-componentenlaag en niet als losse pagina-opbouw of domeinafhankelijkheid.	Vastgelegd	Hoofdstuk 24
TO-BES-034	ArchUnitNET is de primaire tooling voor architecture tests in OefenHub.ArchitectureTests; NetArchTest is geen baseline.	Vastgelegd	Hoofdstuk 02, 23
TO-BES-035	PDF-regressietests gebruiken primair structurele Verify/PdfPig-snapshots en beperken visuele golden masters tot stabiele kernlayouts; byte-identieke PDF-vergelijking is geen primaire regressiemethode.	Vastgelegd	Hoofdstuk 16, 23
TO-BES-036	De initiële materialisatiekandidaten voor readmodels zijn vastgesteld; mailbox-, badge-, ticket-, guardian-summary- en zware beheerprojecties zijn kandidaat, terwijl geschiedenisdetails, PDF-export en live availability querymatig of runtime blijven tenzij meetgegevens anders aantonen.	Vastgelegd	Hoofdstuk 17, 22
TO-BES-037	Beheerbare seeddata voor popups, systeemberichttemplates, systeeminstellingen, featuretoggles, notificaties en contentblokken gebruikt stabiele technische keys, create-if-missing-seeding en expliciete migratie/backfill voor technische wijzigingen; beheerwaarden worden niet stilzwijgend overschreven.	Vastgelegd	Hoofdstuk 07, 13, 20
TO-BES-038	Aspire-developmentpariteit is gevalideerd als development-only inrichting met vaste guardrails voor scope, projectgrens, configuratiebinding, secrets, lokale data en observability; productiegebruik van Aspire vereist een nieuw besluit.	Vastgelegd	Hoofdstuk 20
TO-BES-039	De MudBlazor- en OefenHub-componentenstrategie is gevalideerd: MudBlazor blijft Web-only componentbasis, OefenHub levert theme en herbruikbare wrappercomponenten, en HTML-mockups blijven ontwerpinput in plaats van implementatiecode.	Vastgelegd	Hoofdstuk 24
TO-BES-040	De backup- en restorebaseline gebruikt een RPO van maximaal 5 × 24 uur en een RTO van maximaal 3 werkdagen na restorebesluit; high-availability, active-active, hot standby en zero-downtime restore vallen buiten de V1.0-baseline.	Vastgelegd	Hoofdstuk 21, 25
TO-BES-041	De V1.0-performancegrenzen per hoofdflow zijn vastgesteld als lichte richtwaarden voor acceptabele performance; OefenHub krijgt geen top-tier latency- of high-scale-performancebaseline.	Vastgelegd	Hoofdstuk 22, 23
TO-BES-042	EF Core migration history staat per persistente module-DbContext in het eigen schema als __EFMigrationsHistory; een centrale gedeelde historytabel zonder contextonderscheid is niet toegestaan.	Vastgelegd	Hoofdstuk 07, 23
TO-BES-043	Tijdelijke PDF-output wordt buiten webroot opgeslagen via OefenHub:Reporting:TempExportPath, standaard na 24 uur cleanupeligible en minimaal iedere 6 uur opgeschoond; achterstand vanaf 48 uur wordt zichtbaar gemaakt.	Vastgelegd	Hoofdstuk 16, 18, 21, 25
TO-BES-044	Blazor componenttests gebruiken bUnit en end-to-endtests gebruiken Playwright .NET; E2E-dekking blijft beperkt tot primaire smoke- en regressieflows.	Vastgelegd	Hoofdstuk 23, 24
TO-BES-045	SignalR live-reconnect gebruikt vijf automatische pogingen met delays 0, 2, 10, 30 en 60 seconden; na falen toont de UI een veilige verbroken status en wordt actuele server-side state bij reconnect opnieuw opgehaald.	Vastgelegd	Hoofdstuk 15, 22, 23, 24
TO-BES-046	Serilog-/Seq-configuratie en logretentie zijn vastgesteld als lichte V1.0-baseline met centrale configuratie, Seq als interne viewer, privacybewuste scrubbing en begrensde retentietermijnen per omgeving/logcategorie.	Vastgelegd	Hoofdstuk 19, 21, 25
TO-BES-047	Securityevents blijven standaard technische logs in Serilog/Seq; er komt geen generieke persistente securityeventtabel of apart securityschema in V1.0. Persistente opslag gebeurt alleen wanneer een domeinactie functioneel bronhoudende historie vereist.	Vastgelegd	Hoofdstuk 19, 20, 25
TO-BES-048	De CSP-baseline staat externe bronnen standaard niet toe, gebruikt geen inline scripts, staat inline styles alleen beperkt toe voor Blazor/MudBlazor, en wordt centraal in OefenHub.Web als header geconfigureerd.	Vastgelegd	Hoofdstuk 20, 23, 24
TO-BES-049	Rate limiting wordt per routecategorie ingericht met lichte V1.0-limieten voor publieke pagina's, login/provisioning, Blazor UI, relaties, berichten, tickets, search/filter, PDF-export, beheer, SignalR en interne tooling.	Vastgelegd	Hoofdstuk 20, 22, 23
TO-BES-050	De eerste technische oefenmodulecategorie is Arithmetic en de eerste concrete technische oefenmodule is OefenHub.Modules.Arithmetic.AdditionSubtractionSimple, functioneel beschreven als Optellen & Aftrekken (simpel) binnen het moduledossier oefen_modules/rekenen/optellen_en_aftrekken_simpel.	Vastgelegd	Hoofdstuk 02, 03, 09, 23
TO-BES-051	Cross-module transaction boundaries voor V1.0-kritieke workflows zijn gevalideerd; primaire bronmutaties liggen bij de functionele eigenaar en afgeleide signalering, readmodels, caches, PDF-generatie, e-mail en SignalR blijven idempotent of retrybaar waar dat veilig is.	Vastgelegd	Hoofdstuk 03, 07, 12, 14, 18, 25, 26
TO-BES-052	Moq is de baseline mockinglibrary voor interface-gebaseerde unit-testmocks, tenzij een concrete testbehoefte of security-/dependencyreview een afwijking vereist.	Vastgelegd	Hoofdstuk 23
TO-BES-053	Technische logging gebruikt Engelstalige eventnamen, propertynamen en vaste logmessage-templates; gebruikersgerichte teksten blijven Nederlandstalig.	Vastgelegd	Hoofdstuk 19
TO-BES-054	Retrydefaults per jobtype zijn vastgesteld als lichte V1.0-baseline met beperkte retries voor periodieke/onderhoudsjobs, ruimere retries voor maildelivery en beheer-/supportgestuurde hersteljobs.	Vastgelegd	Hoofdstuk 18, 21, 23
TO-BES-055	De secretbaseline voor de eerste Docker-livegang gebruikt met het huidige inzicht file-based secrets via Docker Compose secrets, read-only secretbestanden of, bij Swarm, Docker/Portainer secrets; de exacte route blijft afhankelijk van deploymentinrichting.	Vastgelegd	Hoofdstuk 20, 21

26.5 Implementatieverificaties en aandachtspunten

Onderstaande punten blokkeren de V1.0-baseline niet, maar moeten vóór of tijdens implementatie aantoonbaar worden opgelost. Punten met status “Escaleren naar Functioneel Ontwerp, Software Requirements Specification of database-informatie” mogen niet uitsluitend als technische keuze worden afgehandeld.

ID	Aandachtspunt	Status	Gewenste uitkomst	Primaire verwijzing binnen het Technisch Ontwerp
TO-OPEN-001	TickerQ-tabellen in schema scheduling plaatsen.	Implementatieverificatie	Concrete configuratie voor schema, migrations en deployment.	Hoofdstuk 18, 21
TO-OPEN-002	TickerQ-webinterface intern beschikbaar en afgeschermd maken.	Implementatieverificatie	Alleen intern/bevoegd toegankelijk dashboard met logging van beheeracties.	Hoofdstuk 18, 20, 21

26.6 Workflowmatrix voor transactionele keuzes

Voor iedere cross-module workflow wordt in het relevante hoofdstuk of in het register een compacte matrix gebruikt. De matrix voorkomt dat kritieke stappen per ongeluk retrybaar worden gemaakt of dat niet-kritieke side-effects onnodig atomair worden gekoppeld.

Veld	Invulling
Workflow	Naam van de gebruikersactie of achtergrondactie.
Functionele eigenaar	Module die de workflow inhoudelijk bezit.
Betrokken modules	Modules die via publieke contracten worden aangeroepen.
Kritieke stappen	Stappen die samen de functionele uitkomst bepalen.
Retrybare stappen	Stappen die veilig opnieuw kunnen worden uitgevoerd.
Transaction boundary	Eén moduletransactie, gedeelde transactie, compensatie of failed-status.
Gebruikersfeedback	Wat de gebruiker ziet bij succes, functioneel falen of technisch falen.
Correlation	Welke correlation-id en identifiers in logs/jobs worden vastgelegd.
Herstelpad	Automatische retry, beheeractie, nieuwe gebruikersactie of technische analyse.

Voorbeeld:

Workflow	Functionele eigenaar	Kritieke stappen	Retrybare stappen	Transaction boundary
Relatie-uitnodiging versturen	Relationships	Uitnodiging aanmaken, conflictcontrole, primair systeembericht wanneer dit de enige acceptatie-ingang is	Badge-update, optionele tellerverversing	Atomair voor kritieke stappen; retrybaar voor afgeleide signalering
Ticket oplossen	Support	TicketClosure, statuswijziging, support-history	Systeembericht wanneer dit niet de enige functionele ingang is, badge-update, readmodelverversing	Kritieke supportmutaties atomair; communicatie per workflow classificeren
Tijdelijke PDF cleanup	Scheduling/Reporting	Geen gebruikersgerichte bronmutatie	Bestand verwijderen, technische cleanupstatus	Retrybaar en idempotent

26.7 Richtlijn voor hoofdstukopsplitsing

Hoofdstukken mogen worden opgesplitst wanneer een hoofdstuk te groot wordt voor onderhoud, review of navigatie. Opsplitsen is wenselijk wanneer één hoofdstuk meerdere zelfstandige technische beslisgebieden bevat die afzonderlijk wijzigen.

Signaal	Actie
Hoofdstuk bevat meerdere zelfstandige technische subdomeinen	Splitsen in subpagina's of detaildocumenten.
Tabellen of matrices domineren het hoofdstuk	Overweeg een registerbestand naast het hoofdstuk.
Eén onderdeel wijzigt veel vaker dan de rest	Verplaats dat onderdeel naar een apart onderhoudbaar document.
Inhoud is vooral status-/besluitregistratie	Plaats detail in register en houd hoofdstuk samenvattend.
Docusaurus-navigatie wordt onoverzichtelijk	Maak een indexpagina met onderliggende detailpagina's.

Bij opsplitsing blijven Docusaurus-links extensieloos en blijft de inhoudelijke bronvolgorde gelijk: Functioneel Ontwerp en Software Requirements Specification voor functionele regels, database-informatie voor datamodelbroninformatie en Technisch Ontwerp voor technische implementatiekeuzes.

26.8 Documentatie-impact bij stories en technische wijzigingen

Iedere story of technische wijziging beoordeelt expliciet of bovenliggende documentatie geraakt wordt. Een wijziging is pas documentatiecompleet wanneer alle geraakte bronnen zijn bijgewerkt of bewust als niet geraakt zijn beoordeeld.

Impactgebied	Vraag
Functioneel Ontwerp-impact	Verandert een functionele regel, rolgedrag, lifecycle of gebruikersflow?
Software Requirements Specification-impact	Verandert een requirement, acceptatiecriterium, prioriteit of traceability?
Technisch Ontwerp-impact	Verandert projectstructuur, modulecontract, workflow, job, logging, security of infrastructuur?
Database-informatie-impact	Verandert een tabel, kolom, relatie, constraint, enum, snapshot of datamodelbronregel?
ERD-impact	Verandert een relatie of datamodelstructuur die visueel moet worden bijgewerkt?
Schermdocumentatie-impact	Verandert schermgedrag, labels, velden, foutmeldingen, filters of zichtbare acties?
Usecase-impact	Verandert actorinteractie, hoofdflow, alternatieve flow of foutflow?
Testimpact	Verandert benodigde unit-, integratie-, architecture-, security- of end-to-endtests?

26.9 Relatie met het detailregister

Het detailregister wordt gebruikt voor praktische opvolging. Dit hoofdstuk blijft de samenvattende baseline-laag van het Technisch Ontwerp. Wanneer een aandachtspunt definitief wordt opgelost, zijn er drie mogelijke uitkomsten:

1. het besluit wordt verwerkt in het relevante hoofdstuk van het Technisch Ontwerp;
2. het punt wordt verplaatst naar Functioneel Ontwerp, Software Requirements Specification of database-informatie omdat het geen puur technische keuze blijkt;
3. het punt wordt bewust buiten de huidige baseline geplaatst en blijft met reden zichtbaar in het register.

Het register mag geen tweede bron worden voor technische regels die al definitief in hoofdstukken zijn verwerkt. Definitieve regels horen in het relevante hoofdstuk van het Technisch Ontwerp; het register bewaakt status, besluitvorming en opvolging.

26.10 Baseline-controle voor het Technisch Ontwerp

Voor het Technisch Ontwerp als geheel gelden bij baseline minimaal de volgende controles:

Controle	Verwachting
Hoofdstukken	Alle hoofdstukken van het Technisch Ontwerp zijn inhoudelijk uitgewerkt of bewust buiten de huidige baseline geplaatst.
Aandachtspunten	Ieder aandachtspunt heeft status, eigenaar of vervolgroute.
Besluiten	Belangrijke technische keuzes zijn traceerbaar in dit hoofdstuk of het register.
Links	Docusaurus-links zijn extensieloos.
Tabellen	Markdown-tabellen zijn syntactisch geldig.
Bronvolgorde	Het Technisch Ontwerp spreekt Functioneel Ontwerp, Software Requirements Specification en database-informatie niet tegen.
Datamodel	Tabeldetails blijven in database-informatie; het Technisch Ontwerp beschrijft vertaling en implementatiekeuzes.
Security	Security is beschreven ondanks ontbreken van een apart securityproject.
Logging	Correlation, privacygrenzen en foutafhandeling zijn uitgewerkt.
Jobs	TickerQ, scheduling, retries, failed-statussen en beheerbaarheid zijn beschreven.
Privacy	Retentie, anonimisering, snapshots en exports zijn technisch afgebakend.
Teststrategie	Module-, integratie-, architecture-, security- en end-to-endtestlijnen zijn beschreven.