Domeindatatypes

Domeindatatypes

Binnen elk domein, en dus ook binnen het WOZ domein, zijn er naast entiteiten zoals WOZ object, Perceel of Persoon ook datatypes die domeinspecifiek zijn zoals WOZ objectnummer, BSN of KVK nummer. Vaak is het zo dat deze datatypes uiteindelijk in de programmatuur gerepresenteerd worden als taal-native datatypes: In sommige gevallen voldoet een Integer, terwijl in eigenlijk alle gevallen uiteindelijk een String voldoet om de data in op te slaan.

Toch kiezen wij ervoor om in de meeste gevallen wel (universeel gebruikte) entiteiten te definiëren voor deze datatypen: WozObjectnummer, KadastraalObjectId, maar ook Ingangsdatum kun je terugvinden in onze codebase, terwijl Kotlin-native String of LocalDateTime had kunnen volstaan. We doen dit om in de code explicieter te (kunnen) zijn over deze entiteiten, en op die manier oneigenlijke manipulatie van deze entiteiten zoveel als mogelijk te voorkomen. Je kan Kadastraal object id's op deze manier bijvoorbeeld niet meer concateneren of in een functieaanroep verwarren met een WOZ objectnummer: het zijn geen Strings, het zijn eigen entiteiten.

De vraag bij dergelijke detailmodellering van je domein is altijd: hoe ver ga je? Het antwoord is opinionated; wij houden de volgende richtlijnen aan:

1. De entiteit moet binnen het betreffende domein als term 'algemeen' bekend zijn.
2. De entiteit moet bepaalde eigenschappen hebben die specifieker zijn dan de taal-algemene variant. Bijvoorbeeld:
   • BSN-nummers kunnen een voorloopnul hebben en zijn niet 'optelbaar'
   • Kadastrale Objecten hebben een hele specifieke formatting: Ze beginnen altijd met NL.IMKAD.KadastraalObject en hebben een vast aantal volgende cijfers.
   • Ingangsdata kunnen bijvoorbeeld niet vallen op feestdagen.
3. De data in deze expliciete datatypes dient uiteindelijk ergens opgeslagen te worden. Het gaat (naar ons idee) te ver om ook de opslaglaag (persistentie), zoals een database of AxonServer, te voorzien van deze expliciete types. Hier is dus een vertaalslag noodzakelijk. Deze vertaalslag is geëncapsuleerd in 'persistentie omliggende code', zoals repository classes. Op deze manier is er weinig impact op business logica, hoeven standaard opslag componenten niet aangepast te worden en is transformatiecode goed testbaar en controleerbaar.
4. Datatypes die voortkomen uit techniek blijven 'native' datatypes. Denk aan Eventtijdstippen (opgeleverd door Axon Framework) of sequences uit een relationele database.