Gebeurtenisbronnenpatroon

In plaats van alleen de huidige status van de gegevens op te slaan in een relationele database, slaat u de volledige reeks acties op die zijn uitgevoerd op een object in een opslag met alleen toevoeggegevens. Het archief dient als het systeem van records en kan worden gebruikt voor het realiseren van de domeinobjecten. Deze aanpak kan de prestaties, schaalbaarheid en controlebaarheid in complexe systemen verbeteren.

Context en probleem

De meeste toepassingen werken met gegevens en de gebruikelijke benadering is dat de toepassing de meest recente status van de gegevens in een relationele database opslaat, gegevens indien nodig invoegt of bijwerkt. In het traditionele CRUD-model (create, read, update en delete) is een typisch gegevensproces bijvoorbeeld het lezen van gegevens uit de store, het aanbrengen van enkele wijzigingen in de gegevens en het bijwerken van de huidige status van de gegevens met de nieuwe waarden, vaak door transacties te gebruiken die de gegevens vergrendelen.

De CRUD-benadering is eenvoudig en snel voor de meeste scenario's. In systemen met hoge belasting heeft deze aanpak echter enkele uitdagingen:

• Prestaties: naarmate het systeem wordt geschaald, verslechteren de prestaties vanwege conflicten voor resources en vergrendelingsproblemen.

• Schaalbaarheid: CRUD-systemen zijn synchroon en gegevensbewerkingen blokkeren op updates. Dit kan leiden tot knelpunten en hogere latentie wanneer het systeem wordt belast.

• Controlebaarheid: CRUD-systemen slaan alleen de meest recente status van de gegevens op. Tenzij er een controlemechanisme is waarmee de details van elke bewerking in een afzonderlijk logboek worden vastgelegd, gaat de geschiedenis verloren.

Oplossing

Het gebeurtenisbronnenpatroon definieert een benadering voor het afhandelen van bewerkingen op gegevens die op een reeks gebeurtenissen is gebaseerd. Elke gebeurtenis wordt vastgelegd in een archief waaraan alleen gegevens kunnen worden toegevoegd. Toepassingscode genereert gebeurtenissen die de actie die op het object is ondernomen, imperatief beschrijven. De gebeurtenissen worden over het algemeen verzonden naar een wachtrij waarbij een afzonderlijk proces, een gebeurtenis-handler, naar de wachtrij luistert en de gebeurtenissen in een gebeurtenisarchief persistent maakt. Elke gebeurtenis vertegenwoordigt een logische wijziging in het object, zoals AddedItemToOrder of OrderCanceled.

De gebeurtenissen worden definitief in een gebeurtenisarchief opgeslagen. Dit fungeert als het recordsysteem (de gezaghebbende gegevensbron) voor de huidige status van de gegevens. Aanvullende gebeurtenis-handlers kunnen luisteren naar gebeurtenissen waarin ze geïnteresseerd zijn en een passende actie ondernemen. Een gebruiker kan bijvoorbeeld taken initiëren die de bewerkingen in de gebeurtenissen toepassen op andere systemen, of een andere eraan gekoppelde actie uitvoeren die is vereist om de bewerking te voltooien. De toepassingscode waarmee de gebeurtenissen worden gegenereerd, wordt losgekoppeld van de systemen die zich op de gebeurtenissen abonneren.

Op elk moment is het mogelijk voor toepassingen om de geschiedenis van gebeurtenissen te lezen. Vervolgens kunt u de gebeurtenissen gebruiken om de huidige status van een entiteit te materialiseren door alle gebeurtenissen af te spelen en te gebruiken die zijn gerelateerd aan die entiteit. Dit proces kan op aanvraag plaatsvinden om een domeinobject te materialiseren bij het verwerken van een aanvraag.

Omdat het relatief duur is om gebeurtenissen te lezen en opnieuw af te spelen, implementeren toepassingen doorgaans gerealiseerde weergaven, alleen-lezenprojecties van het gebeurtenisarchief die zijn geoptimaliseerd voor het uitvoeren van query's. Een systeem kan bijvoorbeeld een gerealiseerde weergave onderhouden van alle klantorders die worden gebruikt om de gebruikersinterface te vullen. Wanneer de toepassing nieuwe orders toevoegt, items toevoegt of verwijdert in de order of verzendgegevens toevoegt, worden gebeurtenissen gegenereerd en wordt de gerealiseerde weergave bijgewerkt door een handler.

In de afbeelding ziet u een overzicht van het patroon, waaronder enkele typische implementaties met het patroon, waaronder het gebruik van een wachtrij, een alleen-lezenarchief, het integreren van gebeurtenissen met externe toepassingen en systemen en het opnieuw afspelen van gebeurtenissen om projecties te maken van de huidige status van specifieke entiteiten.

Werkproces

Hieronder wordt een typische werkstroom voor dit patroon beschreven:

1. De presentatielaag roept een object aan dat verantwoordelijk is voor het lezen vanuit een alleen-lezenarchief. De geretourneerde gegevens worden gebruikt om de gebruikersinterface te vullen.
2. De presentatielaag roept opdrachthandlers aan om acties uit te voeren, zoals het maken van een winkelwagen of het toevoegen van een item aan de winkelwagen.
3. De opdrachthandler roept het gebeurtenisarchief aan om de historische gebeurtenissen voor de entiteit op te halen. Het kan bijvoorbeeld alle winkelwagen-gebeurtenissen ophalen. Deze gebeurtenissen worden afgespeeld in het object om de huidige status van de entiteit te materialiseren voordat er actie wordt ondernomen.
4. De bedrijfslogica wordt uitgevoerd en gebeurtenissen worden gegenereerd. In de meeste implementaties worden de gebeurtenissen naar een wachtrij of onderwerp gepusht om de gebeurtenisproducenten en gebeurtenisgebruikers los te koppelen.
5. Gebeurtenis-handlers luisteren naar gebeurtenissen waarin ze geïnteresseerd zijn en voeren de juiste actie uit voor die handler. Enkele typische gebeurtenis-handleracties zijn:
   1. De gebeurtenissen naar het gebeurtenisarchief schrijven
   2. Een alleen-lezenarchief bijwerken dat is geoptimaliseerd voor query's
   3. Integreren met externe systemen

Patroonvoordelen

Het gebeurtenisbronnenpatroon biedt de volgende voordelen:

• Gebeurtenissen zijn onveranderlijk en kunnen worden opgeslagen met een bewerking waarbij alleen gegevens kunnen worden toegevoegd. De gebruikersinterface, de werkstroom of het proces dat een gebeurtenis heeft geïnitieerd, kan door blijven gaan, en taken die de gebeurtenissen verwerken kunnen op de achtergrond worden uitgevoerd. Dit proces, gecombineerd met het feit dat er geen conflicten zijn tijdens de verwerking van transacties, kan de prestaties en schaalbaarheid voor toepassingen aanzienlijk verbeteren, met name voor de presentatielaag.

• Gebeurtenissen zijn eenvoudige objecten die een bepaalde actie beschrijven die is opgetreden, samen met eventuele gekoppelde gegevens die nodig zijn om de actie te beschrijven die wordt vertegenwoordigd door de gebeurtenis. Gebeurtenissen werken een gegevensarchief niet rechtstreeks bij. Ze worden op het juiste moment slechts geregistreerd voor verwerking. Het gebruik van gebeurtenissen kan de implementatie en het beheer vereenvoudigen.

• Gebeurtenissen hebben doorgaan betekenis voor een domeinexpert, terwijl vanwege objectrelationele onverenigbaarheid complexe databasetabellen soms lastig te begrijpen zijn. Tabellen zijn kunstmatige constructies die de huidige status van het systeem vertegenwoordigen, niet de gebeurtenissen die hebben plaatsgevonden.

• Met gebeurtenisbronnen kan worden voorkomen dat gelijktijdige updates conflicten veroorzaken, omdat de vereiste voor het rechtstreeks bijwerken van objecten in het gegevensarchief wordt vermeden. Het domeinmodel moet echter nog steeds zodanig worden ontworpen dat aanvragen die tot een inconsistente status kunnen leiden, worden voorkomen.

• De opslag van alleen toevoeggebeurtenissen biedt een audittrail die kan worden gebruikt om acties te bewaken die zijn uitgevoerd op een gegevensarchief. De huidige status kan opnieuw worden gegenereerd als gerealiseerde weergaven of projecties door de gebeurtenissen op elk gewenst moment opnieuw af te spelen en kan helpen bij het testen en opsporen van fouten in het systeem. Bovendien kan de vereiste om compenserende gebeurtenissen te gebruiken om wijzigingen te annuleren een geschiedenis bieden van wijzigingen die zijn omgekeerd. Deze mogelijkheid zou niet het geval zijn als het model de huidige status heeft opgeslagen. De lijst met gebeurtenissen kan ook worden gebruikt om de prestaties van toepassingen te analyseren en trends in gebruikersgedrag te detecteren. Of kan worden gebruikt om andere nuttige bedrijfsgegevens te verkrijgen.

• De opdrachthandlers genereren gebeurtenissen en taken voeren bewerkingen uit als reactie op deze gebeurtenissen. Deze ontkoppeling van de taken van de gebeurtenissen biedt flexibiliteit en uitbreidbaarheid. De taken kennen het type en de datum van de gebeurtenis, maar niet de bewerking die de gebeurtenis heeft geactiveerd. Bovendien kan elke gebeurtenis door meerdere taken worden verwerkt. Hierdoor is eenvoudige integratie mogelijk met andere services en systemen die alleen letten op nieuwe gebeurtenissen die door het gebeurtenissenarchief worden geactiveerd. De gebeurtenissen met betrekking tot gebeurtenisbronnen zijn meestal van een erg laag niveau. Het kan daarom noodzakelijk zijn in plaats daarvan specifieke integratiegebeurtenissen te genereren.

Gebeurtenisbronnen worden vaak gecombineerd met het CQRS-patroon door de gegevensbeheertaken uit te voeren als reactie op de gebeurtenissen en door weergaven van de opgeslagen gebeurtenissen te materialiseren.

Problemen en overwegingen

Beschouw de volgende punten als u besluit hoe u dit patroon wilt implementeren:

• Uiteindelijke consistentie : het systeem is alleen consistent bij het maken van gerealiseerde weergaven of het genereren van projecties van gegevens door gebeurtenissen opnieuw af te spelen. Er is enige vertraging tussen een toepassing die gebeurtenissen toevoegt aan het gebeurtenisarchief als gevolg van het verwerken van een aanvraag, de gepubliceerde gebeurtenissen en de consumenten van de gebeurtenissen die deze verwerken. Tijdens deze periode kunnen gebeurtenissen waarin verdere wijzigingen aan entiteiten worden beschreven, in het gebeurtenissenarchief zijn binnengekomen. Uw klanten moeten in orde zijn met het feit dat gegevens uiteindelijk consistent zijn en dat het systeem moet worden ontworpen om rekening te houden met uiteindelijke consistentie in deze scenario's.

  Notitie

  Zie de inleiding tot gegevensconsistentie voor meer informatie over uiteindelijke consistentie.

• Versiebeheergebeurtenissen : het gebeurtenisarchief is de permanente bron van informatie en daarom mogen de gebeurtenisgegevens nooit worden bijgewerkt. De enige manier om een entiteit bij te werken of een wijziging ongedaan te maken, is door een compenserende gebeurtenis toe te voegen aan het gebeurtenisarchief. Als het schema (in plaats van de gegevens) van de persistente gebeurtenissen moet worden gewijzigd, bijvoorbeeld tijdens een migratie, kan het lastig zijn om bestaande gebeurtenissen in het archief te combineren met de nieuwe versie. Uw toepassing moet wijzigingen in gebeurtenisstructuren ondersteunen. Dit kan op verschillende manieren.

  • Zorg ervoor dat uw gebeurtenis-handlers alle versies van gebeurtenissen ondersteunen. Dit kan een uitdaging zijn om te onderhouden en te testen. Hiervoor moet u een versiestempel implementeren op elke versie van het gebeurtenisschema om zowel de oude als de nieuwe gebeurtenisindelingen te onderhouden.
  • Implementeer een gebeurtenis-handler om specifieke gebeurtenisversies af te handelen. Dit kan een onderhoudsvraag zijn in die foutoplossing die wijzigingen mogelijk moet doorvoeren in meerdere handlers. Hiervoor moet u een versiestempel implementeren op elke versie van het gebeurtenisschema om zowel de oude als de nieuwe gebeurtenisindelingen te onderhouden.
  • Werk historische gebeurtenissen bij naar het nieuwe schema wanneer een nieuw schema wordt geïmplementeerd. Hierdoor wordt de onveranderbaarheid van gebeurtenissen verbroken.

• Gebeurtenisvolgorde : toepassingen met meerdere threads en meerdere exemplaren van toepassingen kunnen gebeurtenissen opslaan in het gebeurtenisarchief. De consistentie van gebeurtenissen in het gebeurtenissenarchief is van vitaal belang, evenals de volgorde van gebeurtenissen die van invloed is op een bepaalde entiteit (de volgorde waarin wijzigingen aan een entiteit optreden, beïnvloedt de huidige status ervan). Door een tijdstempel aan elke gebeurtenis toe te voegen kunnen problemen worden voorkomen. Een andere veelgebruikte methode bestaat uit het toevoegen van aantekeningen aan elke gebeurtenis die het gevolg zijn van een aanvraag met een incrementele id. Als twee acties tegelijkertijd gebeurtenissen voor dezelfde entiteit willen toevoegen, kan het gebeurtenissenarchief een gebeurtenis weigeren die overeenkomt met een bestaande entiteit-id en gebeurtenis-id.

• Query's uitvoeren op gebeurtenissen : er is geen standaardbenadering of bestaande mechanismen zoals SQL-query's, voor het lezen van de gebeurtenissen om informatie te verkrijgen. De enige gegevens die kunnen worden geëxtraheerd zijn een stroom gebeurtenissen die een gebeurtenis-id als criteria gebruiken. De gebeurtenis-id is doorgaans toegewezen aan afzonderlijke entiteiten. De huidige status van een entiteit kan alleen worden bepaald door alle gebeurtenissen die er betrekking op hebben, opnieuw af te spelen tegen de oorspronkelijke status van die entiteit.

• Kosten voor het opnieuw maken van de status voor entiteiten : de lengte van elke gebeurtenisstroom is van invloed op het beheren en bijwerken van het systeem. Als de stromen groot zijn, kunt u op bepaalde tijdstippen momentopnamen maken, bijvoorbeeld van een bepaald aantal gebeurtenissen. De huidige status van de entiteit kan uit de momentopname worden verkregen en door alle gebeurtenissen die na dat tijdstip zijn opgetreden, opnieuw af te spelen. Zie De replicatie van primaire onderliggende momentopnamen voor meer informatie over het maken van momentopnamen van gegevens.

• Conflicten : hoewel gebeurtenisbronnen de kans op conflicterende updates voor de gegevens minimaliseren, moet de toepassing nog steeds inconsistenties kunnen verwerken die het gevolg zijn van uiteindelijke consistentie en het ontbreken van transacties. Een gebeurtenis die aangeeft dat een voorraadvermindering in de voorraad kan binnenkomen in het gegevensarchief terwijl een bestelling voor dat item wordt geplaatst. Deze situatie resulteert in een vereiste om de twee bewerkingen af te stemmen, hetzij door de klant te adviseren of door een terugbestelling te maken.

• Noodzaak voor idempotentie - Gebeurtenispublicatie kan ten minste één keer zijn, en dus moeten consumenten van de gebeurtenissen idempotent zijn. Zij moeten de update die in een gebeurtenis staat beschreven, niet opnieuw toepassen als de gebeurtenis vaker wordt verwerkt. Meerdere exemplaren van een consument kunnen de eigenschap van een entiteit onderhouden en aggregeren, zoals het totale aantal geplaatste orders. Er moet slechts één slagen in het verhogen van de aggregaties, wanneer er een order geplaatste gebeurtenis plaatsvindt. Hoewel dit resultaat geen belangrijk kenmerk is van gebeurtenisbronnen, is dit de gebruikelijke implementatiebeslissing.

• Kringlogica : houd rekening met scenario's waarbij de verwerking van één gebeurtenis betrekking heeft op het maken van een of meer nieuwe gebeurtenissen, omdat dit een oneindige lus kan veroorzaken.

Wanneer dit patroon gebruiken

Gebruik dit patroon in de volgende scenario's:

• Als u de bedoeling, het doel of de reden in de gegevens wilt vastleggen. Wijzigingen in een klantentiteit kunnen bijvoorbeeld worden vastgelegd als een reeks specifieke gebeurtenistypen, zoals Verplaatst huis, Gesloten account of Overleden.

• Als het cruciaal is het optreden van conflicterende updates aan gegevens te minimaliseren of volledige te voorkomen.

• Wanneer u gebeurtenissen wilt vastleggen die zich voordoen, om ze opnieuw af te spelen om de status van een systeem te herstellen, wijzigingen terug te draaien of om een geschiedenis en auditlogboek te behouden. Wanneer een taak bijvoorbeeld meerdere stappen omvat, moet u mogelijk acties uitvoeren om updates terug te zetten en vervolgens enkele stappen opnieuw afspelen om de gegevens weer in een consistente status te brengen.

• Wanneer u gebeurtenissen gebruikt. Het is een natuurlijk kenmerk van de werking van de toepassing en vereist weinig extra ontwikkel- of implementatie-inspanning.

• Wanneer u het invoerproces wilt loskoppelen of gegevens wilt bijwerken van de taken die nodig zijn om deze acties toe te passen. Deze wijziging kan zijn om de prestaties van de gebruikersinterface te verbeteren of om gebeurtenissen te distribueren naar andere listeners die actie ondernemen wanneer de gebeurtenissen plaatsvinden. U kunt bijvoorbeeld een salarissysteem integreren met een website voor het indienen van onkosten. De gebeurtenissen die door het gebeurtenisarchief worden gegenereerd als reactie op gegevensupdates die op de website zijn aangebracht, worden gebruikt door zowel de website als het salarissysteem.

• Als u flexibiliteit wilt om de indeling van gerealiseerde modellen en entiteitsgegevens te wijzigen als de vereisten veranderen, of, wanneer deze worden gebruikt met CQRS, moet u een leesmodel of de weergaven aanpassen die de gegevens beschikbaar maken.

• Wanneer het wordt gebruikt met CQRS en uiteindelijke consistentie acceptabel is terwijl een leesmodel wordt bijgewerkt, of de invloed van de prestaties van het reactiveren van entiteiten en gegevens uit een gebeurtenisstroom acceptabel is.

Dit patroon is wellicht niet geschikt in de volgende situaties:

• Toepassingen waarvoor geen hyperschaal of prestaties nodig zijn.

• Kleine of eenvoudige domeinen, systemen met weinig of geen bedrijfslogica of niet-domeinsystemen die in het algemeen goed werken met traditionele CRUD-gegevensbeheermechanismen.

• Systemen waarbij consistentie en updates aan de weergaven van de gegevens in realtime zijn vereist.

• Systemen waarbij er slechts weinig conflicterende updates zijn voor de onderliggende gegevens. Bijvoorbeeld systemen die hoofdzakelijk gegevens toevoegen in plaats van ze bij te werken.

Workloadontwerp

Een architect moet evalueren hoe het patroon Gebeurtenisbronnen kan worden gebruikt in het ontwerp van hun workload om de doelstellingen en principes te verhelpen die worden behandeld in de pijlers van het Azure Well-Architected Framework. Voorbeeld:

Net als bij elke ontwerpbeslissing moet u rekening houden met eventuele compromissen ten opzichte van de doelstellingen van de andere pijlers die met dit patroon kunnen worden geïntroduceerd.

Opmerking

Een conferentiebeheersysteem moet het aantal voltooide reserveringen voor een conferentie bijhouden. Op deze manier kan worden gecontroleerd of er nog seats beschikbaar zijn wanneer een potentiële deelnemer probeert een reservering te maken. Het systeem kan het totale aantal reserveringen voor een conferentie op ten minste twee manieren opslaan:

• Het systeem kan informatie over het totale aantal reserveringen opslaan als een aparte entiteit in een database waarin de reserveringsgegevens worden bewaard. Als er reserveringen worden gedaan of geannuleerd, kan dit aantal worden verhoogd respectievelijk verlaagd. Deze benadering is in theorie eenvoudig, maar kan aanleiding geven tot schaalbaarheidsproblemen als een groot aantal deelnemers in korte tijd plaatsen wil reserveren. Bijvoorbeeld op de laatste dag voordat de reserveringsperiode afloopt.

• Het systeem kan informatie over reserveringen en annuleringen opslaan als gebeurtenissen die in een gebeurtenissenarchief worden bewaard. Vervolgens kan het aantal beschikbare plaatsen worden berekend door de gebeurtenissen opnieuw af te spelen. Deze benadering kan meer schaalbaar zijn vanwege de onveranderlijkheid van de gebeurtenissen. Het systeem hoeft alleen maar gegevens te lezen in het gebeurtenissenarchief of gegevens toe te voegen aan het gebeurtenissenarchief. Gebeurtenisinformatie over reserveringen en annuleringen wordt nooit gewijzigd.

In het volgende diagram wordt getoond hoe het subsysteem voor het reserveren van plaatsen van het conferentiebeheersysteem kan worden geïmplementeerd door middel van gebeurtenisbronnen.

De volgorde van de acties voor het reserveren van twee plaatsen is als volgt:

1. De gebruikersinterface geeft de opdracht plaatsen te reserveren voor twee deelnemers. De opdracht wordt afgehandeld door een aparte opdrachthandler. Dit is een stukje logica dat wordt ontkoppeld van de gebruikersinterface en verantwoordelijk is voor het afhandelen van aanvragen die als opdrachten zijn gepost.

2. Een entiteit met informatie over alle reserveringen voor de conferentie wordt samengesteld door een query uit te voeren op de gebeurtenissen die boekingen en annuleringen beschrijven. Deze entiteit wordt aangeroepen SeatAvailabilityen bevindt zich in een domeinmodel dat methoden beschikbaar maakt voor het uitvoeren van query's en het wijzigen van de gegevens in de entiteit.

   Sommige optimalisaties waarmee u rekening moet houden, maken gebruik van momentopnamen (zodat u de volledige lijst met gebeurtenissen niet hoeft op te vragen en opnieuw af te spelen om de huidige status van de entiteit te verkrijgen) en een kopie in de cache van de entiteit in het geheugen te onderhouden.

3. De opdrachthandler roept een methode aan die door het domeinmodel beschikbaar wordt gemaakt om reserveringen te maken.

4. De SeatAvailability entiteit genereert een gebeurtenis die het aantal gereserveerde seats bevat. De volgende keer dat de entiteit gebeurtenissen toepast, worden alle reserveringen gebruikt om te berekenen hoeveel seats er blijven.

5. Het systeem voegt de nieuwe gebeurtenis toe aan de lijst met gebeurtenissen in het gebeurtenissenarchief.

Als een gebruiker een plaats annuleert, volgt het systeem een soortgelijk proces. Hierbij wordt een opdracht gegeven waarmee een annuleringsgebeurtenis wordt gegenereerd die aan het gebeurtenissenarchief wordt toegevoegd.

Naast het bieden van meer schaalbaarheidsbereik, biedt het gebruik van een gebeurtenisarchief ook een volledige geschiedenis of audittrail van de reserveringen en annuleringen voor een conferentie. De gebeurtenissen in het gebeurtenissenarchief zijn vormen de juiste record. Het is niet nodig om aggregaties op een andere manier te behouden, omdat het systeem de gebeurtenissen eenvoudig opnieuw kan afspelen en de status op elk gewenst moment kan herstellen.

Volgende stappen

• Object-relationele impedantie komt niet overeen

• Inleiding over gegevensconsistentie. Wanneer u gebeurtenisbronnen gebruikt met een afzonderlijk leesarchief of gerealiseerde weergaven, zijn de leesgegevens niet onmiddellijk consistent. In plaats daarvan zijn de gegevens alleen uiteindelijk consistent. In dit artikel vindt u een overzicht van de problemen met betrekking tot het onderhouden van consistentie over gedistribueerde gegevens.

• Richtlijnen voor gegevenspartitionering. Gegevens worden vaak gepartitioneerd wanneer u gebeurtenisbronnen gebruikt om de schaalbaarheid te verbeteren, conflicten te verminderen en de prestaties te optimaliseren. In dit artikel wordt beschreven hoe u gegevens opsplitst in afzonderlijke partities en welke problemen zich kunnen voordoen.

• Blog van Martin Fowler:

  • Gebeurtenisbronnen
  • Momentopname op de website van Enterprise Application Architecture van Martin Fowler

Verwante resources

De volgende patronen en richtlijnen zijn mogelijk ook relevant bij de implementatie van dit patroon:

• CQRS-patroon (Command and Query Responsibility Segregation). Het leesarchief (de permanente bron van informatie voor een CQRS-implementatie) wordt vaak gebaseerd op een implementatie van het gebeurtenisbronnenpatroon. Het beschrijft hoe de bewerkingen die gegevens in een toepassing lezen, door middel van afzonderlijke interfaces moeten worden gescheiden van de bewerkingen die gegevens bijwerken.

• Gerealiseerde weergave-patroon. Het gegevensarchief dat wordt gebruikt in een systeem dat is gebaseerd op gebeurtenisbronnen, is doorgaans niet geschikt voor efficiënte query's. Daarom worden vaak weergaven van de gegevens gegenereerd die vooraf zijn ingevuld. Dit kan op regelmatige basis zijn of als de gegevens worden gewijzigd.

• Patroon Compenserende transactie. De bestaande gegevens in een gebeurtenisbronnenarchief worden niet bijgewerkt. In plaats daarvan worden nieuwe vermeldingen toegevoegd die de status van entiteiten overschakelen naar de nieuwe waarden. Als u een wijziging wilt omkeren, worden compenserende vermeldingen gebruikt omdat het niet mogelijk is om de vorige wijziging om te keren. Beschrijft hoe het werk dat door een eerdere bewerking is uitgevoerd, ongedaan kan worden gemaakt.