Files
register-referentie/docs/architecture/fds/adr/0006-module-boundary-and-reuse.md
T
ehoandClaude Opus 5 700399992a
CI / lint (pull_request) Successful in 1m26s
CI / build (pull_request) Successful in 1m13s
CI / unit (pull_request) Successful in 1m39s
CI / frontend (pull_request) Successful in 3m32s
CI / mutation (pull_request) Successful in 6m33s
CI / verify-stack (pull_request) Successful in 8m16s
docs(architecture): import the FDS architecture decisions (refs #159)
Bring the engineer-facing FDS documentation next to the code it
describes: ADR-0001 to ADR-0006, the ADR index and template, the L3
component view, and the slice-1 proposal. All translated to Dutch.
Source: projects/open-register-fd/ in Respellion/innovation-lab.

Land the set in docs/architecture/fds/ rather than docs/architecture/.
This repo already owns adr-0001-loose-coupling to adr-0004-bdd-framework,
so a flat import collides on every number. The subfolder keeps the
imported numbering, and with it about thirty ADR-000N cross-references
in the imported text.

Add the mermaid custom fence to pymdownx.superfences. Without it the
imported diagrams publish as raw code blocks, because the site has no
mermaid support today. Add the nav group and one link from the docs
index.

The blueprint, the FDS gap analysis and the privacy views stay in the lab
repo; the OKRs cite them and they feed tender responses.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-03 11:29:07 +02:00

4.3 KiB

ADR-0006: Modulegrens en hergebruikstrategie voor de governed-access spine

  • Status: accepted
  • Datum: 2026-06-13
  • Deciders: Lab Circle (Lead Link, Build, Upstream Liaison)
  • Vervangt / vervangen door:

Context

De compliance-spine uit slice 1 bestaat uit de PDP-controle (ADR-0003), gegoverneerd uitgaand verkeer via FSC (ADR-0002), emissie van het verwerkingenlog (ADR-0005), en de begrensde cache (ADR-0004), allemaal achter ports (ADR-0001). Die spine is mogelijk breder herbruikbaar dan alleen in de referentie-applicatie.

Er spelen twee hergebruikvragen: welke verpakkingsvorm kiezen wij, en hoe verhoudt de spine zich tot andere omgevingen zoals het OpenMetadata-datagovernanceproject?

Twee verduidelijkingen bepalen het besluit.

  1. OpenMetadata is geen afnemer. In het datagovernanceproject is het de catalogus- en lineage-laag over (synthetische) data. Het bevraagt geen BRP of NHR. FSC of de begrensde cache daarin inbouwen zou zinloos zijn. De juiste aansluiting is integratie van de output van de spine, en niet het inbouwen van de spine.
  2. FSC en de begrensde cache zijn zaken die alleen een afnemer aangaan. "Maak het herbruikbaar" mag deze niet uitsmeren over componenten die geen registerdata bevragen.

Nu al een taalonafhankelijke gateway bouwen — vóórdat er een tweede, niet-.NET afnemer bestaat — zou de valkuil van speculatieve architectuur herhalen, die wij voor de capability-laag al hebben afgewezen.

Besluit

Wij nemen een vraaggestuurde reeks van vier stappen aan. Elke stap hangt af van echte behoefte, en niet van verwachte behoefte.

Stap Wat Wanneer
1 In-process bewijzen. Bouw de spine als gewone componenten achter ports, binnen de .NET register-applicatie. Nog geen extractie. Doel: de compliance-invarianten één keer echt valideren. Slice 1
2 Extraheren als .NET-module. Zodra een tweede .NET-afnemer in zicht is, haal de spine eruit als een geversioneerde .NET-library of SDK. Dit is de ACL-template-extractie die het charter al plant. Herbruikbaar voor .NET-afnemers, en dat is genoeg voor register-reference en zijn broertjes. Slice 3
3 De feed LDV naar OpenMetadata aansluiten. Route verwerkingsevents uit de LDV-emitter naar OpenMetadata als access- en usage-metadata bij het geclassificeerde asset: wie las welk persoonsgegevensveld, met welk doel, hoe vaak. Optioneel laten classificatietags uit OpenMetadata terugstromen om veldminimalisatie in de ACL aan te sturen. Dit is de concrete brug tussen beide anchor-projecten: integratie, geen inbouw. Na stap 2
4 Alleen op verzoek een taalonafhankelijke gateway bouwen. Heeft een echte niet-.NET afnemer gegoverneerde registertoegang nodig, verpak de spine dan als zelfstandige sidecar of proxy met een dunne lokale API, met PDP, FSC-egress en LDV erachter. Niet eerder. Op verzoek

Gevolgen

Positief: eigen software blijft minimaal. Hergebruik volgt op validatie in plaats van eraan vooraf te gaan. Beide anchor-projecten krijgen een concreet, benoemd integratiepunt (stap 3). Zaken die alleen een afnemer aangaan, blijven ingesloten.

Negatief en kosten: de .NET-module uit stap 2 dient geen niet-.NET afnemers. Dat aanvaarden wij, omdat stap 4 dat geval dekt zodra het echt is. Stap 3 vraagt een afgesproken schema voor het verwerkingsevent, stabiel genoeg voor OpenMetadata om te consumeren.

Vervolgwerk:

  1. Neem stap 3 als expliciet integratiepunt op in beide projectpagina's in het Innovation Lab-repo: projects/open-register-fd/README.md en projects/openmetadata/README.md.
  2. Herzie de trigger van stap 4 bij elke portfolio-review. Bouw niet vooruit.
  3. Regel governance op het schema van het verwerkingsevent; dat is een gedeelde afhankelijkheid van stap 1 en stap 3.

Overwogen alternatieven

  • De taalonafhankelijke gateway vooraf bouwen — afgewezen: speculatieve architectuur voordat er een tweede afnemer bestaat. De latency en de operationele kosten zijn niet te rechtvaardigen.
  • De spine in OpenMetadata inbouwen — afgewezen: OpenMetadata is geen afnemer. Dit is een categoriefout.
  • De spine permanent in-process houden, zonder extractie — afgewezen: dat geeft het hergebruik tussen projecten en applicaties weg, en dat is een kerndoel van de Open Register-inzet.