WOZ Use cases

In dit document beschrijven we de use cases die uitgewerkt zijn in deze code base. Hou in gedacht dat we in deze handreiking niet de volledige WOZ casus willen overnemen ( zie uitgangspunten). De uitleg van de use cases is bedoeld als context om de code beter te begrijpen, niet een functionele specificatie.

WOZ BRK beoordeling

In de WOZ BRK beoordeling package package wordt een ( fictief) WOZ proces uitgewerkt. In deze use case krijgt het WOZ systeem perceelmutaties vanuit de brk te verwerken (die binnen komen via de BRK bridge, zie ook het patroon Bounded Context Bridge) die door een medewerker beoordeeld moeten worden. Als een perceel gesplitst is, is het niet per definitie gelijk duidelijk op welke nieuwe percelen de nog bestaande WOZ objecten thuis horen.

Om deze beoordeling te kunnen doen heeft de medewerker een projectie nodig van de relevante informatie, en is er een command handler om de daadwerkelijke beoordeling te kunnen doen.

BRK herstel van tenaamstelling

De Kadastrale registratie kan fouten bevatten door onder andere foutieve registratie. Als deze fouten opgemerkt worden, worden deze hersteld. In dit project hebben we hier het herstel van een tenaamstelling opgenomen als voorbeeld van hoe herstel plaats zou kunnen vinden. Vanuit de BRK ontvangt de WOZ de correctie. Via de bridge en command handler wordt dit event overgenomen in de WOZ registratie als een BelangGecorrigeerdNavFouteRegistratieBRK event.

Bij dit event wordt het geldigheidstijdstip interessant, want deze ligt dus altijd in het verleden. Dit levert dus extra werk op voor alle projecties die iets doen met tenaamstellingen.

Mijn WOZ objectopvraging door een burger

Een burger moet in staat zijn om de state van een WOZ object op te vragen, waarbij historische states ook opvraagbaar dienen te zijn, zowel op de materiele als de verwerkingstijdslijn. Op deze manier kan de burger zien wat er met zijn of haar WOZ object gebeurd is in de loop van de tijd.

Twijfelen

Twijfel: Wat is het (niet)?

Interactie met burgers, bedrijven, interne of andere overheden ligt in een CRM-achtig (zaak) systeem
Impact van twijfel wordt wél opgenomen in 'het register' (binnen de bounded context van het betreffende, voor nu WOZ, domein).Dit gebeurt op twee assen:
- Een bevoegde (externe) instantie kan een terugmelding doen en daarmee stellen dat gegeven( s) in de registratie niet kloppen.
- binnen het registratiedomein kan, al dan niet als gevolg van 1 of meerdere terugmeldingen, een onderzoek starten naar entiteiten in het domein.
Terugmeldingen zijn alleen van buiten het register zichtbaar voor de meldende instantie
Onderzoeken zijn ook van buiten in te zien door anderen dan de meldende instantie.
Terugmeldingen en onderzoeken hebben eigen IDs en een eigen lifecycle (gerelateerd aan maar in principe los van herstel)
Er kunnen meerdere terugmeldingen/onderzoeken (met eigen id's) zijn naar dezelfde gegevens/events.
Er kan aan meerdere gegevens tegelijkertijd getwijfeld worden.
Twijfel kan geïnterpreteerd worden als 'mate van zekerheid' over een gegeven, dat uitgedrukt zou kunnen worden in een percentage. Binnen de context van dit document is dat niet waar we het over hebben bij twijfel: twijfel is 'binair': Een bevoegde instantie twijfelt aan bepaalde gegeven(s) of niet.

Waar wordt aan getwijfeld?

Een of meerdere (wozobject)gegevens in een projectie
Een of meerdere (wozobject)gegevens in een event

Terugmeldingen

In een terugmelding kan een bevoegde instantie een twijfel aangeven aan ene WOZ object, waarbij uit de omschrijving zo duidelijk als mogelijk is aangegeven wordt wat het onderwerp van de twijfel is.

Een terugmelding kan ook gaan over een woz object dat naar mening van de bevoegde instantie ontbreekt. Een dergelijke terugmelding kan pas aan het relevante object gekoppeld worden bij herstel (en het aanmaken van dit betreffende woz object).

Onderzoeken

Naar aanleiding van een terugmelding kan een onderzoek gestart worden. Binnen het onderzoek dient uitgezocht te worden of de terugmelding terecht is, en zo ja wat de oorzaak van de fout is. Hierin zijn een aantal opties:

1 of meerdere Events ontbreken
1 of meerdere Events zijn incorrect (door een fout van een aanleverende instantie, medewerker, softwarefout of combinatie van deze drie).
Er zit een softwarefout in een projectie.

Binnen het onderzoek dient de aangeleverde informatie zo gestructureerd als mogelijk vastgelegd te worden, om afnemers zo specifiek mogelijk te kunnen informeren over het lopende onderzoek. Dit moet ook, lopende het onderzoek, in meerdere stappen kunnen.

Conceptueel model

referentie naar de 'zaak' -> grondslag
Status van twijfel: (melding, gerede twijfel, in onderzoek, foutief gegeven, twijfel gecorrigeerd)
Type twijfel (ontbrekend gegeven, incorrect gegeven, onvolledig gegeven)
korte toelichting (uit grondslag)

Lifecycle

De eerste aanleiding van twijfel is dat er in een view een gegeven niet klopt, ontbreekt of mist.
In onderzoek zal achterhaald moeten worden welk gevolg de bron van het twijfelachtige gegeven is. hoe?
Als de twijfel gegrond is zal een herstelproces gestart moeten worden om fout te herstellen.
Vervolgens kan na controle door de indiener of een autoriteit de twijfel weggenomen worden.
twijfelen aan twijfel? In eerste instantie 1 tijdlijn voor twijfel: de eventtijdlijn.

twijfel lifecycle

Twijfel aan gegeven(s)

Zolang we nog nog niet baseren permanente projecties kunnen we enkel gestructureerd melding maken van foutieve gegevens in events: fouten in projecties kunnen enkel aangegeven worden met referentie naar ID. Aangezien projecties en projectiemomenten qua structuur en inhoud naar verloop van tijd kunnen wijzigen, en sterk beïnvloedt kunnen worden door viewleverende software en replays biedt dit geen robuuste structuur om met bijvoorbeeld jsonpath verwijzingen te maken.

Als het foutieve gegeven enkel in een projectie blijkt te zitten, en er dus sprake is van een softwarefout, dan kunnen we deze herstellen en dit als zodanig benoemen in het onderzoek. Maar we kunnen daarna niet meer terugreferen naar de foutsituatie (op dit moment).

Van twijfel aan gegeven naar twijfel aan gevolg

Hoe doet een medewerker dat? Moeten we hier een UI voor bouwen?

Projecties

Algemene business rules kunnen altijd bepalen wanneer welke terugmeldingen en onderzoeken wanneer zichtbaar wordt in welke projectie.

De bekendheid van (gestructureerde) informatie bepaalt hoe specifiek we kunnen zijn in projecties.

Voorbeelden

Twijfel, onderzoek en herstel aan 1 entiteit

Na overdracht van eigendom: 1 van de eigenaren klopt niet, zou Pietje moeten zijn, niet Jantje

Iemand (een afnemer?) merkt op dat er iets onjuist is en meld dat terug
1. Gebruiker meld terug dat de eigenaar onjuist is
2. De TerugmeldingCommandHandler controleert of het opgegeven WOZ Object bestaat
3. Als deze bestaat, wordt een terugmelding gedaan gevolg geproduceerd
4. TODO Terugmeldingen zijn, per terugmelder, in te zien in de terugmeld projectie
  
  Dit is ter ondersteuning dat afnemers formeel mogen afwijken van de gegevens die in dit register worden gepresenteerd. Er is namelijk wettelijk bepaald (per domein wel enigszins verschillend) dat bepaalde gegevens verplicht bij een bron opgehaald dienen te worden en er uitsluitend afgeweken mag worden ná terugmelding.
Naar aanleiding van een terugmelding start een onderzoek. Dit onderzoek wordt getwijfeld aan een bepaald gegeven
1. Gebruik start onderzoek naar WOZ Objecten die in de terugmelding opgegeven zijn
2. De OnderzoekCommandHandler controleert:
  1. Of alle opgegeven WOZ Objecten bestaan én
  2. Of de gegevens bestaan waarnaar verwezen wordt in het commando: twijfelAanGegeven
3. Als alle controles zonder problemen doorlopen zijn, wordt het onderzoek gestart inclusief alle WOZ Objecten, twijfel aan gegevens en terugmeldingen
4. Er zijn meerdere projecties die worden bijgewerkt:
  1. De burger kan zijn of er actuele onderzoeken zijn bij mijn WOZ Objecten
  2. Onderzoekers kunnen alle onderzoeken met details inzien tbv het werkproces
Tijdens het uitvoeren van de onderzoeken wordt vastgesteld welk gevolg fout is
1. Onderzoeker raadpleegt de WOZ Objecten projectie incl. historie en alle details. Per historische snapshot is ook beschikbaar om welk gevolg ten grondslag ligt aan die betreffende snapshot.
2. Onderzoeker stelt vast welk gevolg een onjuiste situatie heeft veroorzaakt
3. Onderzoeker werkt onderzoek bij met het ID van het gevolg dat de onjuiste situatie heeft veroorzaakt met omschrijving "Jantje zou pietje moeten zijn."
4. De OnderzoekCommandHandler controleert:
  1. Of het onderzoek (nog) niet is afgerond
  2. Of alle gegevens bestaan waarnaar verwezen wordt in het commando: twijfelAanGegeven
  3. Of alle gevolgen bestaan waarnaar verwezen wordt in het commando: twijfelAanGevolgen
  4. Of alle gegevens bestaan waarnaar verwezen wordt van die gevolgen in het commando: betreftEntiteit
5. Als alle controles zonder problemen doorlopen zijn, wordt het onderzoek bijgewerkt
6. Uiteraard wordt dit weer zichtbaar in alle projecties
herstel + afronding onderzoek en afronding terugmelding

Geïmplementeerd in TwijfelEnHerstelVoorbeeldTest

Snapshots in Woz-objectprojectie:

WOZ nr	Geldigheid	gevolgtijdstip	projectietijdstip	oorzaak van nieuwe snapshot
1	16-02-25 T0	17-02-25 T1	17-02-25 T2	Object geregistreerd
1	01-03-25 T1	01-03-25 T2	01-03-25 T3	overdracht
1	01-03-25 T1	01-04-25 T1	01-04-25 T2	onderzoek gestart
1	01-03-25 T1	15-04-25 T1	15-04-25 T2	herstel
1	01-03-25 T1	15-04-25 T3	15-04-25 T4	onderzoek afgerond

Alternatieve flows:

Iemand (een afnemer?) merkt onterecht op dat er iets onjuist is en meld dat terug
1. Gebruiker meld terug dat de eigenaar onjuist is
2. De TerugmeldingCommandHandler controleert of het opgegeven WOZ Object bestaat -> WOZ Object bestaat niet!
3. Er wordt wél terugmelding gedaan gevolg geproduceerd en direct wordt ook terugmelding afgehandeld met als opmerking melding onterecht

Of:

Iemand (een afnemer?) merkt onterecht op dat er iets onjuist is en meld dat terug
1. De OnderzoekCommandHandler controleert:
  1. Of alle opgegeven WOZ Objecten bestaan én
  2. Of de gegevens bestaan waarnaar verwezen wordt in het commando: twijfelAanGegeven
2. Als alle controles zonder problemen doorlopen zijn, wordt het onderzoek gestart inclusief alle WOZ Objecten, twijfel aan gegevens en terugmeldingen
3. Er zijn meerdere projecties die worden bijgewerkt:
  1. De burger kan zijn of er actuele onderzoeken zijn bij mijn WOZ Objecten
  2. Onderzoekers kunnen alle onderzoeken met details inzien tbv het werkproces
Tijdens het uitvoeren van de onderzoeken wordt vastgesteld dat er geen fout is en dus een onterechte terugmelding
1. Onderzoeker raadpleegt de WOZ Objecten projectie incl. historie en alle details. Per historische snapshot is ook beschikbaar om welk gevolg ten grondslag ligt aan die betreffende snapshot.
2. Onderzoeker stelt vast dat er GEEN onjuist situatie is
3. Onderzoeker rond onderzoek af waarmee ook de terugmelding afgehandeld is met melding onterechte melding

Of:

start onderzoek op woz object
...

Of:

start onderzoek op 'niks'
...

Twijfel aan en herstel van ontbrekend gegeven

Alleen testgeval Bij overdracht ontbreekt een van de 2 eigenaren.

Twijfel aan en herstel van een bug in een projectie

Na terugmelding blijkt dat er een bug in 1 van de projecties zit: de gevolgen zijn goed vastgelegd; deze zijn echter niet goed zichtbaar in de projectie. Bij een overdracht wordt alleen de 1e eigenaar vastgelegd.

Kadastraal object wordt geregistreerd.
Er vindt een overdracht plaats.
Iemand (een afnemer?) merkt op dat er een specifieke projectie op een specifiek moment onjuist is en meldt dat terug (met bij voorkeur een UUID van de projectie). Er wordt een onderzoek gestart, en uit dat onderzoek blijkt dat er een bug in de projectie zit: verwerking is goed gegaan en gevolgen zijn correct.
Het ontwikkel/beheerteam fixt de bug en doet een replay op de toestanden: voor de foutsituatie worden nieuwe snapshots geproduceerd.
Onderzoek wordt afgerond.

Snapshots in Woz-objectprojectie:

WOZnr	Geldigheid	gevolgtijdstip	projectietijdstip	oorzaak van nieuwe snapshot
1	16-02-25	17-02-25	17-02-25 T2	Object geregistreerd
1	01-03-25 T1	01-03-25 T2	01-03-25 T3	overdracht
1	01-03-25 T1	01-04-25 T1	01-04-25 T2	onderzoek gestart
1	01-03-25 T1	01-04-25	15-04-25	replay
1	01-03-25 T1	16-04-25 T1	16-04-25 T2	onderzoek afgerond

Twijfel: onderzoek en herstel van meerdere woz objecten

WOZnr	Geldigheid	gevolgtijdstip	projectietijdstip	oorzaak van nieuwe snapshot
1	16-01-25	17-01-25 T1	17-01-25 T2	Object geregistreerd
2	16-02-25	17-02-25 T1	17-01-25 T2	Object geregistreerd
1	01-03-25 T1	01-03-25 T2	01-03-25 T3	overdracht
1	01-03-25 T1	01-04-25 T1	01-04-25 T2	onderzoek gestart
2	16-02-25	01-04-25 T1	01-04-25 T3	onderzoek gestart
1	01-03-25 T1	03-04-25 T1	03-04-25 T2	onderzoek geupdate
2	16-02-25	03-04-25 T1	03-04-25 T3	onderzoek geupdate
1	01-03-25 T1	15-04-25 T1	15-04-25 T2	herstel
2	16-02-25	17-04-25 T1	17-04-25 T2	herstel
1	01-03-25 T1	17-04-25 T1	17-04-25 T3	onderzoek afgerond
2	16-02-25	17-04-25 T1	17-04-25 T4	onderzoek afgerond

Snapshots in Onderzoekprojectie:

onderzoekId	Geldigheid	gevolgtijdstip	projectietijdstip	oorzaak van nieuwe snapshot
10	01-04-25 T1	01-04-25 T1	01-04-25 T3	onderzoek gestart
10	03-04-25 T1	03-04-25 T1	03-04-25 T3	onderzoek geupdate
10	17-04-25 T1	17-04-25 T1	17-04-25 T4	onderzoek afgerond

Snapshots in terugmeldingprojectie:

onderzoekId	Geldigheid	gevolgtijdstip	projectietijdstip	oorzaak van nieuwe snapshot
100	01-04-25 T1	01-04-25 T1	01-04-25 T3	Terugmelding gedaan
100	17-04-25 T1	17-04-25 T1	17-04-25 T4	Terugmelding afgerond

Uitdieping herstel

Even los van de context van twijfel; maar we moeten alle varianten van herstel erkennen? Welke zijn dat allemaal?

Veelvoorkomende twijfel: herstel van belanghebbende(n)

nieuw command/nieuwe events -> Marc! Foutief eigenaarschap.

Fout gegeven in projectie dat niet terug herleidbaar is naar een bug of gevolgfout (?)

-> is dit echt een ding?

Onherstelbare foutsituatie

-> leuke voor herstel/postherstel

Twijfel aan een niet meer actueel gegeven in gevolg

Er zijn 2 overdrachten geweest: van A naar B en van B naar C. Nu blijkt echter dat B niet correct was, maar D had moeten zijn.

WOZ BRK beoordeling​

BRK herstel van tenaamstelling​

Mijn WOZ objectopvraging door een burger​

Twijfelen​

Twijfel: Wat is het (niet)?​

Waar wordt aan getwijfeld?​

Terugmeldingen​

Onderzoeken​

Conceptueel model​

Lifecycle​

Twijfel aan gegeven(s)​

Van twijfel aan gegeven naar twijfel aan gevolg​

Projecties​

Voorbeelden​

Twijfel, onderzoek en herstel aan 1 entiteit​

Twijfel aan en herstel van ontbrekend gegeven​

Twijfel aan en herstel van een bug in een projectie​

Twijfel: onderzoek en herstel van meerdere woz objecten​

Uitdieping herstel​

Veelvoorkomende twijfel: herstel van belanghebbende(n)​

Fout gegeven in projectie dat niet terug herleidbaar is naar een bug of gevolgfout (?)​

Onherstelbare foutsituatie​

Twijfel aan een niet meer actueel gegeven in gevolg​