Dit model beschrijft de doel-architectuur. De C4-containers zijn een logische decompositie: ze drukken verantwoordelijkheden en koppelvlakken uit, niet de fysieke deploybare eenheden. In de huidige implementatie (PoC) zijn meerdere logische containers samengevoegd tot één deploybaar proces.
De implementatie kent twee deploybare Quarkus-services plus drie in-process gedeelde libraries die binnen die services meedraaien (geen eigen proces, geen netwerk-hop):
| Deploybare eenheid | Type | Bevat (logische containers / modules) |
|---|---|---|
services/berichtenmagazijn |
Quarkus-service | Berichtenmagazijn Aanlever API, Ophaal- en Beheer API, Bericht Validatie Service, Autorisatie Service, Publicatie Stream, Retentie Service, Dataopslag (PostgreSQL via Dev Services/compose) |
services/berichtenuitvraag |
Quarkus-service | Berichten Uitvraag Service, Aanmeld Service, en — in-process — Berichtensessiecache en Magazijnregister |
libraries/fbs-berichtensessiecache |
in-process library | Berichtensessiecache-container (Sessiecache-facade); draait binnen berichtenuitvraag |
libraries/fbs-magazijnregister |
in-process library | Magazijnregister-container; draait binnen berichtenuitvraag |
libraries/fbs-common |
in-process library | Gedeelde JAX-RS filters, exception mappers, identificatienummers, Profiel-client |
Sessiecache-facade, maar is bewust geen losse service: het is een Kotlin-internal library die in-process in berichtenuitvraag draait. De facade is het enige publieke koppelvlak; de interne werking (Redis-cache, magazijn-aggregatie) is compile-afgedwongen onzichtbaar. Relaties die in het model als CDI lopen (CDI (in-process facade)) zijn dus in-process method-calls, geen REST.CDI (in-process method-calls), niet via een intern REST-koppelvlak.De logische container-grenzen blijven in het model staan omdat ze de doel-decompositie beschrijven (en de koppelvlakken waarlangs later opgesplitst kan worden). De fysieke groepering hierboven beschrijft wat vandaag daadwerkelijk als één proces deployt.