Ontwerpafweging
Uit het artikel:
You have an aggregate when you have business rules — also known as business invariants — that govern the relationship of those objects.
In Spring Data JDBC implementeer je strong consistency met de Repository.save(aggregate). Hiermee sla je alle objecten in één keer op. Een andere save-actie kan het opslaan NIET onderbreken.
Als er op meerdere repositories een save-actie moet worden uitgevoerd, dan is er sprake van eventual consistency. Gedurende de tijd tussen twee saves is de data nog niet consistent. Bovendien kan een andere actie de data veranderen voordat een tweede save-actie is uitgevoerd.
Als twee processen verschillende onderdelen van dezelfde aggregate proberen te bewerken, dan ontstaat er een onnodige Optimistic Locking exception. Als er te veel van dit soort Exceptions ontstaan, dan kan de performance van de applicatie en/of de gebruikerservaring slechter worden.
Aan de ene kant wil je zoveel mogelijk data strongly consistent houden, maar aan de andere kant wil je ook niet te veel Optimistic Locking Exceptions. Soms is deze afweging makkelijk te maken, maar soms moet je in goed overleg met de domeinexperts om te bepalen wat de meest geschikte oplossing is.
Spring Data en de meeste databases bieden geavanceerder mogelijkheden om transacties te definiëren en te bepalen welke data precies gelockt moet worden bij een specifieke actie. Het is bijvoorbeeld mogelijk om twee save-acties in één transactie te krijgen.
Dit kan echter grote consequenties hebben voor de applicatie en vergt meer kennis van databases.
Daarnaast is het niet altijd mogelijk om dergelijke constructies te maken als de data in verschillende databases wordt opgeslagen (wat tegenwoordig best vaak gebeurt).
We gaan hier in deze cursus niet dieper op in.