Hier komt alles samen. Een rebuild genereert vanuit het canonieke model niet alleen een API, maar het register zelf: de Go-code én de database. Modelleren in Omnium Studio is daarmee geen documentatie — het is het bouwen van een werkend, tijdreisbaar register.
Een rebuild verwerkt het model per domein en levert een compleet, draaiend register op.
Per domein 7 Go-bestanden: structs voor entiteiten, GE's en relaties, methodes, input-types en de registries (Meta/datatype/enum).
De tabelstructuur volgens het Hub + _Data-patroon, met formele en materiële tijd-plumbing waar nodig.
REST/OpenAPI en een dynamische GraphQL-laag bovenop het register — meteen bevraagbaar, inclusief tijdreizen.
Rebuild is herbouwbaar en consistent: hetzelfde model levert hetzelfde register — de basis voor registers on demand.
Een register leeft: het model verandert in de tijd. Omnium houdt de modelhistorie bij en voorziet — ten dele — in migratie bij wijzigingen. Dit is een gebied dat actief wordt uitgebreid.
Niet elke modelwijziging is gelijk. Het verschil bepaalt of bestaande gegevens en API-consumenten ongestoord doorwerken:
Een optioneel veld toevoegen verandert niets aan bestaande records of contracten — die blijven geldig.
Een verplicht veld toevoegen breekt bestaande records: ze missen immers die verplichte waarde.
Twee strategieën om daarmee om te gaan — een open ontwerpvraag waar het register naartoe groeit:
Omdat een register volledig uit het model volgt, kun je gericht registers genereren — niet alleen basisregistraties, maar ook werkmap-registers zoals een zaak, dossier of plan, om informatie registratief en tijdreisbaar vast te leggen.
Modelleer in de UML-IDE en rebuild het tot een draaiend bitemporeel register.
Open Omnium Studio →