Uitgangspunten en doel van dit project
Hoe ontwerp je een overheidsregistratie?
-
Wat moet het systeem kunnen in business termen?
- Per definitie zijn er commando's tbv bijhouding, bijwerken
- Per definitie zijn er queries, informatiebehoeften, bevragingen
- bijhouden van veranderingen over de tijd -> gebeurtenissen
- Het is heel natuurlijk om business verloop over tijd te bespreken in gebeurtenissen
- En daarna / eigenlijk is het ook heel natuurlijk om situaties (stand / state) op een moment in tijd expliciet te maken en te bespreken
- DDD is hier van toepassing en behulpzaam
-
Het nieuwe paradigma onderkent 'gewoon' deze nieuwe manier van werken gemakkelijke en expliciet te maken
- welke bijhouding is er in de business? -> commando's
- welke veranderingen onderkent de business? -> gebeurtenissen
- welke vragen moeten er beantwoord worden -> meerdere projecties
- de bijhouding wil ik ook baseren op de gebeurtenissen (één bron van waarheid)
- standaard capabilities van een overheidsregister, zoals herstel, twijfel, historische bevragingen
- NFRs: beheersbaarheid, reproduceerdbaarheid, betrouwbaarheid -> hoe dan? -> technische architectuur
-
Technische architectuur van het systeem
- Hé, CQRS en Event Sourcing passen wel erg goed bij!
- Event Driven Architectures volgen goed op event sourcing
- conceptueel relationeel model is nog steeds wel relevant en belangrijk
Modellen van een overheidsregistratie
Traditioneel gezien wordt in de automatisering gebruik gemaakt van modellen. Deze modellen zijn altijd een afspiegeling van de werkelijkheid en zijn (dus) altijd een vereenvouding daarvan.
In deze modellen beschrijven we entiteiten (met een id), leggen we relaties met andere entiteiten en beschrijven we de eigenschappen van deze entiteiten. Zo'n model noemen wij het conceptuele model. Een dergelijk conceptueel model is goed in het beschrijven van een momentopname, maar minder goed in het beschrijven van veranderingen over tijd.
We dienen zowel veranderingen als de situatie op een punt in tijd te interpreteren en een plaats te geven. En daarin dienen we ook nog rekenschap af te leggen over de samenhang van de verschillende modellen en van de systemen tov de werkelijkheid op elk moment in tijd. Wij voegen aan het conceptueel model een model van wat er gebeurt in de loop van de tijd, een eventmodel, toe.
Wij nemen het uitgangspunt dat modellen, systemen en implementaties per definitie te kort schieten in de werkelijkheid. Ons uitgangspunt is dat een systeem / implementatie 'Crappy by Design' zou moeten zijn en dus uitzonderingen aan moet kunnen in het gebruikte model als deze zich in de werkelijkheid voordoen. Hierbij is het vooral van belang om te beseffen dat systemen gevolgen hebben voor de werkelijkheid, ook, en misschien wel vooral, als de systemen de uitzonderingen van de werkelijkheid niet juist kunnen weergeven.
Deze uitgangspunten vormen de basis voor meerdere architectuurpatronen: CQRS en Event Sourcing. Het is ook de basis voor de aandacht voor het business domein zoals in Domain Driven Design en stelt eisen aan de modellering van gevolgen en projecties.
De WOZ casus
Voor het realiseren van de Casus WOZ en de voorbeelden uit dit domein, nemen we de volgende uitgangspunten:
-
Het WOZ domein is complex en we gaan niet al deze complexiteit bevatten, beschrijven en/of verbeteren
-
Wij gaan uit van een volledig geautomatiseerde (of digitale) uitvoering en werking van het WOZ domein.
Het WOZ domein zoals het nu is, kent complexiteit die volgt uit historische en bestaande organisatie en werking in de bijhouding. Wij baseren ons hier NIET op, omdat wij als uitgangspunt nemen dat de toekomst volledig digitaal is, tenminste als basis. Mogelijkheden voor menselijk handelen zullen daarin gewaarborgd moeten worden, maar ook dat laten we in beginsel buiten beschouwing.
-
Aangezien de OZ van WOZ slaan op Onroerende Zaak, is de BRK het startpunt van WOZ Objecten. Vervolgens breiden we de bijhouding uit naar Basisregistraties als de BAG en BGT en mogelijke eigen inwinnig van een gemeente (eigen constatering).