Wanneer een plant begint te hangen geven we hem water, wanneer een vriend of vriendin jarig is bakken we een taart en wanneer onze telefoon leeg is laden we hem op. Zomaar een aantal willekeurige gebeurtenissen die plaatsvinden in ons leven waar we er zo nog honderd van op kunnen noemen. Wat ze met elkaar gemeen hebben, is dat er steeds een gebeurtenis was die leidde tot een specifieke actie die verbonden was aan die gebeurtenis – een taart bakken als je telefoon leeg is, helpt immers weinig.
Event-driven architecture werkt eigenlijk volgens hetzelfde principe, maar dan op softwareniveau. Hoe dat werkt en wat daar de voordelen van zijn, leggen we je uit.
Event-driven architecture in 3 componenten
Bij software ontwikkeld vanuit het event-driven architecture model, bepalen gebeurtenissen zoals gebruikersacties welke acties er volgen. Om te snappen hoe dit precies werkt, bespreken we hieronder de 3 componenten waaruit een event-driven architecture bestaat. Om er een beeld bij te krijgen, nemen we de software van een e-commerce platform als voorbeeld.
Event producer
De event producer, de naam zegt het al, produceert een gebeurtenis. In het geval van een e-commerce bedrijf kan dit bijvoorbeeld een aankoop in de webshop zijn, maar bijvoorbeeld ook een vraag die binnenkomt via een app of een retour van een aangekocht product. Het event wordt omgezet naar een actie die gestuurd wordt naar de event router.
Event router
De event router kun je het beste zien als het distributiecentrum van de event-driven architecture. Alle events komen hier binnen, worden gefilterd en doorgestuurd naar de juiste software van de afdeling. Stel een klant doet een aankoop in de webshop: dan stuurt de event router deze gebeurtenis door naar het magazijn waar een melding verschijnt van een nieuwe aankoop.
Event consumer
Het magazijn in bovenstaande toelichting is een perfect voorbeeld van een event consumer. Deze laatste component in de event-driven architecture zet events om in acties. Wanneer er bijvoorbeeld een vraag binnenkomt over een product wordt deze doorgestuurd (via de event router) naar de klantenservice software en kan er een geautomatiseerd bericht verstuurd worden of kan een klantenservicemedewerker contact met de klant opnemen.
De voordelen
Een event-driven architecture heeft een aantal voordelen. Een groot voordeel is dat het uit losgekoppelde elementen bestaat die niet van elkaar afhankelijk zijn. Als één van de ‘producer-router-consumer stromen’ niet meer werkt, blijft de rest van de software gewoon functioneren. Ook voeg je om dezelfde reden gemakkelijk nieuwe diensten (stromen) aan de architectuur toe. Dit maakt event-driven architecture schaalbaar en dynamisch.
beeproger en event-driven architecture
Event-driven architecture is eigenlijk een heel eenvoudig concept: dat is deels ook de kracht. Maar vergis je niet: achter de schermen gebeurt er een hoop. De ‘events’ leggen soms een hele reis af door het systeem. Ze moeten naar verschillende applicaties gestuurd worden die vaak in verschillende talen zijn geschrevenen en verschillende API’s gebruiken. Het opzetten van een sterke event-driven architecture vereist daarom veel kennis en kunde. Onze developers hebben hier gelukkig veel ervaring mee en helpen je graag om een bestaande software nog slimmer en efficiënter in te richten of deze vanaf nul op te bouwen.