Terugmelding, twijfel en correctie van eigenaarschap
Na overdracht van eigendom: 1 van de eigenaren klopt niet, Henk zou Hendrica moeten zijn
- Een afnemer merkt op dat er iets onjuist is en meldt dat terug
- Naar aanleiding van een terugmelding start een onderzoek. Dit onderzoek wordt getwijfeld aan een bepaald gegeven
- Tijdens het uitvoeren van het onderzoek wordt vastgesteld welk gevolg fout is, en de registratie wordt geüpdatet.
- De fout wordt gecorrigeerd, het onderzoek wordt gesloten en de twijfel wordt weggenomen uit het register.
Brondata
CorrectieMetBetwijfelingEnTerugmeldingVoorbeeldTest-use-case-twijfelen-aan-en-corrigeren-van-eigenaarschap-correctie-en-afronding.jsonCommit9fbbe67Opgehaald18 september 2026Dit voorbeeld bouwt voort op de eerdere twijfel- en correctievoorbeelden en laat zien hoe een terugmelding, een betwijfeling en een correctie gecombineerd worden in één scenario (voor meer achtergrond over terugmelding en twijfel, zie de handreiking). In de uitgangspositie is er een WOZ object geregistreerd, en er is een overdracht geweest. Op de projecties van deze overdracht is een terugmelding gekomen, waarna een onderzoek gestart is (in het zaaksysteem). In het register is geregistreerd dat er getwijfeld wordt aan bepaalde gegevens:
Hoe om te gaan met twijfel is zeer domeinafhankelijk. Wat we in dit voorbeeld proberen te illusteren is een vrij typisch scenario in een systeem dat gebouwd is volgens de principes van UBB. Zelfs als deze principes gevolgd worden zijn er nog steeds veel keuzes te maken, zeker voor twijfel.
Afnemers hebben geen zicht op de internals, de gevolgen van het systeem, maar kijken naar projecties. Terugmeldingen, en dus ook de initiële twijfel, zal dus ook gaan over de gegevens in één of meerdere projecties. Lopende het onderzoek zal uitgezocht moeten worden waar de fout precies zit. Hierbij zijn in principe twee mogelijkheden:
- Een softwarefout produceert de projecties verkeerd. De bug zal opgelost moeten worden en er zal een replay gedaan moeten worden.
- Eén of meerdere gevolgen klopt niet. Die zal gecorrigeerd moeten worden.
De eerste optie wordt verder uitgewerkt in het volgende voorbeeld. Dit scenario gaat over mogelijkheid 2.
Lopende het onderzoek is de conclusie gekomen dat het overdrachtsgevolg mogelijk niet klopt. De twijfel wordt bijgewerkt, en wordt specifiek aan het betreffende gevolg gekoppeld:
Nu we weten welke gevolgen betwijfeld worden kunnen we beter communiceren richting al afnemers waarover getwijfeld wordt. In plaats van dat we weten dat er getwijfeld wordt aan één projectiegegeven, weten we nu het gevolg, en kunnen we deze twijfel in alle projecties weergeven. Hoewel een onderzoek niet 'leeft' in het register zelf, dienen we ten behoeve van de informatievoorziening wel een beperkte life cycle van het onderzoek in het register op te nemen. Afhankelijk van de complexiteit van het onderzoekstraject kunnen gegevens betwijfeld worden, twijfel weer weggenomen worden, andere Woz objecten betrokken worden, et cetera. Uiteindelijk moet elk onderzoek leiden naar een oorzaak in de vorm gevolgen die niet kloppen, of een softwarefout. Zodra die conclusie getrokken wordt kunnen we foutieve gegevens corrigeren.
Nu we de conclusie getrokken hebben dat de overdrachtgegevens niet kloppen, kunnen we dit corrigeren. Merk hier op dat de medewerker in de correctie aangegeven heeft dat deze correctie zowel een onderzoek afrondt als een terugmelding afmeldt. Dit betekent dat de correctie ook de twijfel in zijn geheel weg zal nemen.
Verwerking: commando → gevolg
Het commando leidt dan tot meerdere gevolgen, waarin zowel de correctie doorgevoerd wordt als de twijfel weggenomen wordt.
Hoewel al deze gevolgen wel een relatie hebben tot deze entiteit WOZ Object 1, zijn ze niet allemaal relevant op de tijdlijn van deze aggregate. Dan zijn alleen deze relevant:
In de projectie van het WOZ object zie je veel nieuwe lagen bovenop de overdracht. Dit komt omdat deze projectie naast het WOZ object ook de onderzoeksinformatie over dat WOZ object bevat. Elke verandering van het onderzoek leidt in deze projectie tot een nieuwe toestand, ook al verandert het WOZ object zelf niet. Dit illustreert ook het punt (eerder genoemd in dit voorbeeld). Twijfel orthogonaal opnemen in de projecties van entiteiten levert veel mutaties op in je projectie.