Technisch Ontwerp besluiten- en aandachtspuntenregister

Dit register bewaart de praktische detailregistratie van technische ontwerpbesluiten, implementatieverificaties en aandachtspunten. Hoofdstuk Open punten, ontwerpbesluiten en Technisch Ontwerp-besluitenregister bevat de samenvattende baseline-laag; dit register ondersteunt opvolging en controle.

Het register introduceert geen nieuwe functionele requirements en is geen tweede bron voor definitieve technische regels. Definitieve regels horen in het relevante inhoudelijke hoofdstuk van het Technisch Ontwerp. Wanneer een aandachtspunt functionele regels, requirements of datamodelbroninformatie raakt, wordt het geëscaleerd naar het Functioneel Ontwerp, de Software Requirements Specification of database-informatie.

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.

Besluiten

ID	Onderwerp	Status	Verwerkt in	Aantekening
TO-BES-001	Middel-zware modulaire monoliet	Vastgelegd	Hoofdstuk 01, 02, 03	OefenHub wordt uitgewerkt als middel-zware modulaire monoliet: één deploybare applicatie met expliciete modulegrenzen.
TO-BES-002	Eén database en één applicatieconnectionstring	Vastgelegd	Hoofdstuk 02, 07, 20	De eerste technische baseline gebruikt één relationele database en één applicatieconnectionstring.
TO-BES-003	Project, DbContext en schema horen bij elkaar	Vastgelegd	Hoofdstuk 02, 06, 07	Eén domeinproject heeft maximaal één eigen DbContext en daarmee één primair databaseschema.
TO-BES-004	Naamgeving databaseschema's, tabellen en kolommen	Vastgelegd	Hoofdstuk 02, 07	Databaseschema's worden in kleine letters geschreven; tabellen en kolommen gebruiken PascalCase.
TO-BES-005	Geen aparte basisprojecten voor audit, security, workflows of readmodels	Vastgelegd	Hoofdstuk 02, 06, 19, 20	Er komen in de basis geen aparte projecten OefenHub.Audit, OefenHub.Security, OefenHub.Workflows of OefenHub.ReadModels.
TO-BES-006	Domeinspecifieke audit en history	Vastgelegd	Hoofdstuk 06, 14, 19, 25	Audit en history worden primair domeinspecifiek opgeslagen naast de brondata van het domein.
TO-BES-007	Security verdeeld over bestaande lagen	Vastgelegd	Hoofdstuk 19, 20	Security wordt volledig beschreven, maar verdeeld over Web, Infrastructure, Identity, Authorization, Scheduling en domeinmodules.
TO-BES-008	Practice als module voor oefenruns en resultaten	Vastgelegd	Hoofdstuk 02, 10	OefenHub.Practice is de module voor oefenruns, voortgang, resultaten, gedeelde oefeningen en PDF-brondata.
TO-BES-009	Publieke modulecontracten en internal implementaties	Vastgelegd	Hoofdstuk 03	Module-implementaties zijn standaard internal; alleen publieke contracten in Contracts zijn bedoeld voor gebruik door andere modules.
TO-BES-010	Web zonder domeinlogica of DbContext-toegang	Vastgelegd	Hoofdstuk 03, 24	OefenHub.Web bevat UI-compositie, routing en viewmodels, maar geen domeinlogica, DbContexts of module-interne entities.
TO-BES-011	Soft links en snapshots over modulegrenzen	Vastgelegd	Hoofdstuk 06, 07	Cross-module verwijzingen zijn standaard soft links of soft links met snapshot; harde foreign keys over modulegrenzen zijn uitzondering.
TO-BES-012	Foreign key + snapshot binnen domein; soft link over modulegrenzen	Vastgelegd	Hoofdstuk 07, 25	Foreign key + snapshot wordt primair binnen hetzelfde domein toegepast; over modulegrenzen geldt soft link + snapshot als standaardpatroon.
TO-BES-013	Workflowgerichte transaction boundaries	Vastgelegd	Hoofdstuk 03, 07, 12, 14, 18	Per cross-module workflow wordt expliciet bepaald welke stappen onderdeel zijn van de functionele transactie.
TO-BES-014	Kritieke of retrybare systeemberichten per workflow	Vastgelegd	Hoofdstuk 12, 13, 14, 18	Een systeembericht kan kritiek of retrybaar zijn afhankelijk van de functionele rol binnen de workflow.
TO-BES-015	Scheduling als technische jobeigenaar	Vastgelegd	Hoofdstuk 18, 21	OefenHub.Scheduling is eigenaar van de technische joblifecycle zodra een job succesvol is aangemaakt.
TO-BES-016	Domeinmodules blijven eigenaar van jobdomeinlogica	Vastgelegd	Hoofdstuk 18	Domeinmodules blijven eigenaar van de domeinlogica die door jobs wordt uitgevoerd.
TO-BES-017	TickerQ zonder externe message broker	Vastgelegd	Hoofdstuk 18, 21	TickerQ wordt gebruikt voor periodieke en uitgestelde verwerking; er komt geen RabbitMQ of externe message broker in de eerste baseline.
TO-BES-018	Module-eigen readmodels	Vastgelegd	Hoofdstuk 03, 17	Module-eigen readmodels staan onder Models/ReadModels; er komt geen centraal ReadModels-project in de basis.
TO-BES-019	Naamvorm concrete oefenmoduleprojecten	Vastgelegd	Hoofdstuk 02, 09	Concrete oefenmodules gebruiken de naamvorm OefenHub.Modules.<ModuleCategory>.<ModuleName>.
TO-BES-020	Modules.Abstractions als primaire moduleafhankelijkheid	Vastgelegd	Hoofdstuk 09	Concrete oefenmodules gebruiken OefenHub.Modules.Abstractions als primaire afhankelijkheid.
TO-BES-021	SharedKernel alleen bewust en DRY-gedreven	Vastgelegd	Hoofdstuk 03, 09	Gebruik van OefenHub.SharedKernel door concrete oefenmodules is toegestaan wanneer dit aantoonbaar generieke duplicatie voorkomt.
TO-BES-022	PDF-bestanden als tijdelijke output	Vastgelegd	Hoofdstuk 10, 16, 25	PDF-bestanden zijn tijdelijke output; Practice blijft bron van run- en resultaatdata.
TO-BES-023	SignalR als transport	Vastgelegd	Hoofdstuk 10, 15	SignalR is transport voor realtime updates; Practice blijft bron van oefenvoortgang.
TO-BES-024	Testprojecten per module	Vastgelegd	Hoofdstuk 02, 03, 23	Testprojecten worden per module georganiseerd onder een solution folder of fysieke map tests.
TO-BES-025	Architecture tests voor dependencyregels	Vastgelegd	Hoofdstuk 03, 23	Architecture tests bewaken dependencyregels aanvullend op internal en projectreferences.
TO-BES-026	Module-eigen idempotente seeddata	Vastgelegd	Hoofdstuk 07, 08, 13, 20	Seeddata is module-eigen, idempotent en mag beheerbare content niet ongemerkt overschrijven.
TO-BES-027	Correlation-id in relevante technische flows	Vastgelegd	Hoofdstuk 18, 19, 21	Iedere relevante technische flow draagt een correlation-id door voor logging, jobs en cross-module herleidbaarheid.
TO-BES-028	Fallbackgedrag zonder autorisatie-/privacyomzeiling	Vastgelegd	Hoofdstuk 22, 25	Fallbackgedrag mag autorisatie, privacy, brondata of historische reconstructie nooit omzeilen.
TO-BES-029	Vaste anonimiseringswaarden	Vastgelegd	Hoofdstuk 25	Accountanonimisering gebruikt vaste waarden: FirstName = Anoniem, MiddleName = #, LastName = <niet-voorspelbare systeemcode> en Email = anoniem.<code>@verwijderd.acc.
TO-BES-030	Serilog + Seq als loggingbaseline	Vastgelegd	Hoofdstuk 19, 21	Serilog met Seq is de loggingbaseline voor gestructureerde technische logging en centrale loganalyse.
TO-BES-031	Aspire development-only	Vastgelegd	Hoofdstuk 20	Aspire wordt alleen gebruikt als development-only ondersteuning voor configuratie-, dependency- en secrets-pariteit.
TO-BES-032	Geen publieke API of smartphonefocus	Vastgelegd	Hoofdstuk 02, 22, 24	OefenHub heeft in de eerste baseline geen publieke functionele API-laag voor externe clients of mobiele apps; desktop en tablet zijn leidend.
TO-BES-033	MudBlazor met OefenHub-componentenlaag	Vastgelegd	Hoofdstuk 24	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.
TO-BES-034	ArchUnitNET voor architecture tests	Vastgelegd	Hoofdstuk 02, 23	ArchUnitNET is de primaire tooling voor architecture tests in OefenHub.ArchitectureTests; NetArchTest is geen baseline.
TO-BES-035	PDF-regressieteststrategie	Vastgelegd	Hoofdstuk 16, 23	PDF-regressietests gebruiken primair structurele Verify/PdfPig-snapshots en beperken visuele golden masters tot stabiele kernlayouts; byte-identieke PDF-vergelijking is geen primaire regressiemethode.
TO-BES-036	Initiële materialisatiekandidaten voor readmodels	Vastgelegd	Hoofdstuk 17, 22	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.
TO-BES-037	Beheerbare seeddata voor popups, templates en instellingen	Vastgelegd	Hoofdstuk 07, 13, 20	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.
TO-BES-038	Aspire-developmentpariteit gevalideerd	Vastgelegd	Hoofdstuk 20	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.
TO-BES-039	MudBlazor- en componentenstrategie gevalideerd	Vastgelegd	Hoofdstuk 24	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.
TO-BES-040	Backup- en restorebaseline	Vastgelegd	Hoofdstuk 21, 25	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.
TO-BES-041	Performancegrenzen per hoofdflow	Vastgelegd	Hoofdstuk 22, 23	De V1.0-performancegrenzen per hoofdflow zijn vastgesteld als lichte richtwaarden voor acceptabele performance; OefenHub krijgt geen top-tier latency- of high-scale-performancebaseline.
TO-BES-042	EF Core migration history per schema	Vastgelegd	Hoofdstuk 07, 23	EF Core migration history staat per persistente module-DbContext in het eigen schema als __EFMigrationsHistory; een centrale gedeelde historytabel zonder contextonderscheid is niet toegestaan.
TO-BES-043	Tijdelijke PDF-opslag en cleanuptermijn	Vastgelegd	Hoofdstuk 16, 18, 21, 25	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.
TO-BES-044	Blazor componenttests en end-to-endtests	Vastgelegd	Hoofdstuk 23, 24	Blazor componenttests gebruiken bUnit en end-to-endtests gebruiken Playwright .NET; E2E-dekking blijft beperkt tot primaire smoke- en regressieflows.
TO-BES-045	SignalR reconnectinstellingen	Vastgelegd	Hoofdstuk 15, 22, 23, 24	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.
TO-BES-046	Serilog-/Seq-configuratie en logretentie	Vastgelegd	Hoofdstuk 19, 21, 25	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.
TO-BES-047	Securityevents standaard technisch loggen	Vastgelegd	Hoofdstuk 19, 20, 25	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.
TO-BES-048	Content Security Policy baseline	Vastgelegd	Hoofdstuk 20, 23, 24	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.
TO-BES-049	Rate limits per routecategorie	Vastgelegd	Hoofdstuk 20, 22, 23	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.
TO-BES-050	Initiële technische modulecategorie en eerste concrete oefenmodule	Vastgelegd	Hoofdstuk 02, 03, 09, 23	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.
TO-BES-051	Cross-module transaction boundaries voor V1.0-kritieke workflows	Vastgelegd	Hoofdstuk 03, 07, 12, 14, 18, 25, 26	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.
TO-BES-052	Moq als baseline mockinglibrary	Vastgelegd	Hoofdstuk 23	Moq is de baseline mockinglibrary voor interface-gebaseerde unit-testmocks, tenzij een concrete testbehoefte of security-/dependencyreview een afwijking vereist.
TO-BES-053	Engelstalige technische logging	Vastgelegd	Hoofdstuk 19	Technische logging gebruikt Engelstalige eventnamen, propertynamen en vaste logmessage-templates; gebruikersgerichte teksten blijven Nederlandstalig.
TO-BES-054	Retrydefaults per jobtype	Vastgelegd	Hoofdstuk 18, 21, 23	Retrydefaults per jobtype zijn vastgesteld als lichte V1.0-baseline met beperkte retries voor periodieke/onderhoudsjobs, ruimere retries voor maildelivery en beheer-/supportgestuurde hersteljobs.
TO-BES-055	Docker V1.0-secretbaseline	Vastgelegd	Hoofdstuk 20, 21	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.

Implementatieverificaties en aandachtspunten

ID	Onderwerp	Status	Verwerkt in	Vereiste opvolging
TO-OPEN-001	TickerQ-tabellen in schema scheduling	Implementatieverificatie	Hoofdstuk 18, 21	Configuratie, migrations en deployment controleren.
TO-OPEN-002	Interne TickerQ-webinterface	Implementatieverificatie	Hoofdstuk 18, 20, 21	Interne toegang, autorisatie en logging van beheeracties controleren.

Gebruik van dit register

Werk een aandachtspunt bij zodra de bijbehorende verificatie is uitgevoerd of wanneer een nieuw ontwerpbesluit nodig blijkt. Bij verwerking gelden de volgende regels:

1. definitieve technische regels worden verwerkt in het relevante hoofdstuk van het Technisch Ontwerp;
2. functionele of requirementgerichte uitkomsten worden teruggelegd in Functioneel Ontwerp of Software Requirements Specification;
3. datamodelbroninformatie wordt verwerkt in database-informatie;
4. bewust niet opgenomen uitbreidingen krijgen status Buiten huidige baseline;
5. vervallen punten blijven kort traceerbaar met reden wanneer zij eerder besluitvorming hebben beïnvloed.

Bij de V1.0-baseline mogen alleen aandachtspunten met een expliciete status en vervolgroute blijven bestaan.