Implementeren van event sourcing
Er zijn verschillende manieren om gegevens op te slaan in de database. De meest gebruikelijke techniek voor het opslaan van gegevens is door gebruik te maken van het CRUD-patroon. Aanmaken, Lezen, Bijwerken en Verwijderen zijn de vier basisbewerkingen van opslag. In sommige gevallen is het CRUD-patroon niet voldoende om het vereiste doel te bereiken. Een voorbeeld hiervan is een applicatie die financiële gegevens verwerkt.
De CRUD-methode kan handig zijn, maar wat als we elke actie die wordt geactiveerd in de webapplicatie willen vastleggen? Als we het CRUD-patroon volgen, moeten we veel werk verzetten om een acceptabele oplossing te bouwen. Een andere manier om ons doel te bereiken is door een ander patroon toe te passen dat Event Sourcing wordt genoemd.
De belangrijkste vraag is dus: “Waarom het event sourcing-patroon toepassen?”. In deze blog zullen we deze stappen doornemen om ons te helpen deze vraag te beantwoorden:
• Wat is eventsourcing?
• Hoe werkt het?
• Waarom toepassen?
• Voors en tegens
Wat is event sourcing?
De eenvoudigste verklaring is dat Event Sourcing een patroon is voor het opslaan van gegevens als events in een append-only logboek. Door de gebeurtenissen in de database op te slaan, behoudt de gebruiker de context van de gebeurtenissen; ze weten dat er een factuur is verzonden en om welke reden uit dezelfde informatie. Bij andere opslagpatronen gaat de context van de bedrijfsvoering meestal verloren of wordt deze soms ergens anders opgeslagen. Elke aangebrachte wijziging wordt weergegeven als een gebeurtenis en toegevoegd aan het gebeurtenislogboek. In tegenstelling tot CRUD, staat Event sourcing de gebruiker niet toe om de data rechtstreeks te manipuleren. De gebruiker moet eerder gebeurtenissen activeren die dat voor hem doen.
Hoe werkt event sourcing?
Het idee achter event sourcing is om data op te slaan door events te triggeren en in te loggen in de database. De huidige status van een entiteit kan worden gecreëerd door alle gebeurtenissen opnieuw af te spelen in volgorde van voorkomen.
De systeeminformatie is afkomstig van de gebeurtenissen. Omdat de gebeurtenis al heeft plaatsgevonden, wordt er altijd naar verwezen in de verleden tijd.
Het doel hiervan is om te kunnen traceren welke stappen zijn genomen om een proces te starten en te beëindigen.
Event sourcing stelt ons in staat om bij te houden wat het systeem of een gebruiker met de gegevens heeft gedaan.
Waarom event sourcing toepassen?
Event sourcing lost een van de belangrijkste problemen op bij het implementeren van een event-driven architectuur en maakt het mogelijk om betrouwbaar events te publiceren wanneer een bepaalde status verandert.
De focus van dit patroon ligt op gebeurtenissen in plaats van op domeinobjecten. Het is het meest geschikt voor toepassingen die gericht zijn op financiën en het volgen van gebruikersactiviteit in een toepassing.
Velen gaan ervan uit dat Event Sourcing in de eerste plaats bedoeld is voor auditing, maar dit is een beperkte weergave van het patroon. Een append-only logboek is geweldig voor auditing, maar Event Sourcing is zoveel meer dan dat.
Een auditlogboek is een chronologisch verslag van wat er is veranderd zonder enige context. Aangezien de context wordt opgeslagen in de gebeurtenissen, worden het ‘waarom’ en ‘wanneer’ van de gebeurtenis impliciet opgeslagen in de gegevens voor de gebeurtenis. Naast het opstellen van een auditlogboek, bevat een op gebeurtenissen gebaseerd systeem een schat aan informatie en context.
Voors en tegens van event sourcing
Er zijn goede en slechte kanten aan het toepassen van event sourcing:
Voordelen
• Zeer geschikt voor faalveiligheid. Als de stroomafwaartse bron uitvalt, kunnen de gegevens ervan opnieuw worden samengesteld vanuit het gebeurtenisarchief.
• Extreem flexibel. Elk type bericht kan worden opgeslagen. Elke consument heeft toegang tot de evenementenwinkel zolang de juiste toegangsrechten zijn verleend.
• Uitstekend geschikt voor realtime gegevensrapportage
Nadelen
• Vereist een extreem efficiënte netwerkinfrastructuur gezien de inherente tijdgevoeligheid van het patroon en de gevoeligheid voor potentiële latentieproblemen.
• Vereist een betrouwbare manier om berichtindelingen te beheren, bijvoorbeeld met behulp van een schemaregister.
• Verschillende evenementen zullen verschillende payloads bevatten. Er moet één enkele bron van waarheid zijn voor het definiëren en bepalen van berichtformaten voor een bepaalde gebeurtenis.
Conclusie
Event Sourcing is een zeer goede oplossing voor het maken van applicaties die vooral met auditing te maken hebben. Het patroon introduceert veel tools en technieken om gegevens anders te verwerken dan op de traditionele CRUD-manier.
Het is echter ook gemakkelijk om dit patroon op een verkeerde manier toe te passen. Dit kan worden voorkomen door eerst het Event Sourcing-patroon te begrijpen voordat u het toepast. Dit bespaart veel tijd die anders zou worden besteed aan het oplossen van een probleem dat zich in de toekomst kan voordoen.
Het is ook erg belangrijk om de voordelen van Event Sourcing te begrijpen en erachter te komen of de voordelen de nadelen waard zijn.
Hulp nodig bij event sourcing?
Bij Carthago ICT hebben we diverse specialisten die jou kunnen helpen bij het effectief toepassen van event sourcing. Laten we vrijblijvend kennismaken en zien wat we voor elkaar kunnen doen!
