De juiste tools en patronen gebruiken voor eventgestuurde architecturen

Eventgestuurde architecturen ondersteunen de efficiënte productie en consumptie van events, die wijzigingen in systeem- of toepassingsstatus communiceren. Deze architecturen maken flexibele verbindingen mogelijk tussen systemen en ondersteunende processen en vrijwel real-time updates die tussen systemen werken. Hoewel de voordelen van eventgestuurde architecturen duidelijk zijn, zijn implementatiedetails niet altijd even duidelijk. Met welke mogelijkheden moet u rekening houden bij eventgestuurde architectonische patronen? Welke specifieke problemen lossen deze patronen op? Welke speciale overwegingen gelden voor uw oplossingen en wat zijn de optimale patronen om ze aan te pakken?

Deze handleiding presenteert patronen die worden gebruikt voor het samenstellen van optimale eventgestuurde architecturen bij het werken met Salesforce-technologieën. Het bespreekt ook eventingtools die beschikbaar zijn vanuit Salesforce en biedt toolaanbevelingen voor een selectie van gebruikscases. Zie onze Data Integration Decision Guide voor informatie over integraties op gegevensniveau met Salesforce.

• Gebruik eventgestuurde architecturen voor processen die geen synchrone reacties op verzoeken vereisen. De patronen die in deze handleiding worden beschreven, zijn ontworpen voor consistentie, schaalbaarheid en hergebruik van gegevens, waardoor de technische schuldenlast tot een minimum wordt beperkt naarmate het toepassingslandschap van uw organisatie zich ontwikkelt. (Zie Goed ontworpen - doorvoer voor meer informatie.)

• Als MuleSoft of een andere Enterprise Service Bus-oplossing (ESB) deel uitmaakt van uw bestaande landschap, gebruikt u deze waar mogelijk. Deze oplossingen zijn speciaal ontwikkeld om eventgestuurde architectuurpatronen te ondersteunen en hebben krachtige mogelijkheden waarmee u integraties binnen uw onderneming kunt hergebruiken.

• Gebruik de Pub/Sub-API voor toekomstige publicatie-/abonneerpatronen in plaats van uw eigen eventhandlers te maken met behulp van andere API's, waaronder de Streaming-API. Nu de Pub/Sub-API algemeen beschikbaar is, kunt u deze gebruiken voor alle nieuwe publicatie-/abonneerpatronen. Plan het migreren van bestaande eventcommunicatie met behulp van andere platform-API's, zoals de Streaming API of aangepaste Apex services, naar de Pub/Sub-API wanneer dit mogelijk is.

• Platformevents en Change Gegevensvastlegging (CDC) zijn de voorkeursmechanismen voor het publiceren van record- en veldwijzigingen die door andere systemen moeten worden verbruikt. Het wordt afgeraden PushTopic en generieke events te gebruiken voor nieuwe implementaties. Salesforce blijft PushTopic en generieke events ondersteunen binnen de huidige functionele mogelijkheden, maar is niet van plan om verdere investeringen in deze technologie te doen.

Het Salesforce Platform is een uitgebreid, AI-gestuurd platform dat werknemers, autonome AI-agenten, bedrijfsgegevens en toepassingen verenigt in één vertrouwd systeem om de productiviteit en klantervaring te verbeteren. Het maakt het mogelijk om een "agentische onderneming" te maken door Customer 360 apps, Data Cloud en Slack te verbinden voor end-to-end automatisering.

MuleSoft is het toonaangevende integratieplatform van Salesforce waarmee organisaties toepassingen, gegevens en apparaten kunnen verbinden binnen on-premises en cloudomgevingen. MuleSoft is een platform dat IT de platformen biedt om gegevens binnen systemen te ontsluiten, schaalbare integratie- en automatiseringsframeworks te ontwikkelen en gedifferentieerde, verbonden omgevingen te creëren - snel.

Event-Driven Architectures (EDA's) worden aanbevolen voor scenario's die vrijwel realtime kennisgevingen vereisen, de verwerkingsbelasting verdelen voor berichten met groot volume of complexe berichten, en systemen integreren zoals IoT en mobiele apparaten die veerkracht van connectiviteit vereisen via wachtrijen. EDA's mogen echter niet worden geïmplementeerd voor processen die onmiddellijke, synchrone menselijke reacties vereisen, omdat ze zijn ontworpen voor asynchrone uitvoering. Ook zijn ze niet geschikt als brongegevens zo weinig veranderen dat een eenvoudiger patroon zoals batchverwerking zou volstaan.

Hier zijn diverse veel voorkomende scenario's die vaak goed passen bij een eventgestuurde architectuur:

De meeste grote organisaties hebben complexe IT-landschappen met een combinatie van systemen met verschillende mogelijkheden. Het is mogelijk, of waarschijnlijk, dat uw organisatie verouderde systemen heeft die geen ondersteuning bieden voor eventgestuurde integraties. Er zijn mogelijk ook gebruikscases waarin eventgestuurde integraties niet logisch zijn, zelfs als de systemen ze ondersteunen (bijvoorbeeld SFTP-bestandsoverdrachten van derden). Als u een stap terug doet en het IT-landschap van uw organisatie als geheel bekijkt, is de kans groot dat u - net als bij andere architectonische oplossingen - een mix van patronen gebruikt om verschillende scenario's te ondersteunen. Wanneer u besluit om eventgestuurde benadering van integraties uw voorkeur te maken, moet u dit beschouwen als een andere tool in uw toolbox. Het kan en moet in de juiste scenario's worden gebruikt, maar het is niet een benadering die aan elk systeem moet worden opgelegd. Het ontwikkelen van een uitgebreide integratiestrategie helpt u te bepalen wanneer de patronen die in deze handleiding worden beschreven, al dan niet geschikt zijn.

Veel scenario's vereisen eventgestuurde architecturen, en in sommige scenario's werken eventgestuurde architecturen zelfs als ze niet de beste oplossing bieden. Maar in sommige scenario's moeten eventgestuurde architecturen gewoon niet worden gebruikt. Hier zijn enkele beslissingspuntvragen om u te helpen deze scenario's te identificeren:

Er zijn verschillende eventgestuurde architectuurpatronen. Sommige zijn patronen voor algemene doeleinden die kunnen worden toegepast in gebruikscases die geen speciale vereisten hebben, behalve dat ze eventgestuurd zijn; zie bijvoorbeeld Goed ontworpen - Interoperabiliteit. Andere patronen zijn van toepassing op de specifieke gebruikscases die hier worden besproken, zoals integraties met grote gegevensvolumes of scenario's die vragen om langere berichtbewaring.

De onderstaande tabel vergelijkt kenmerken van de in dit document beschreven patronen. Gebruik deze als een snelle naslag wanneer u potentiële patronen voor een bepaalde gebruikscase moet identificeren.

Salesforce biedt meerdere tools om u te helpen uw eventgestuurde gebruikscases aan te pakken. Deze tabel bevat een overzicht op hoog niveau van beschikbare tools.

Wanneer een kritieke record van status verandert binnen een kerntoepassing—de status van een order gaat bijvoorbeeld van "Bezig met verwerken" naar "Verzonden", vereisen meerdere andere systemen waarschijnlijk een vrijwel realtime kennisgeving om hun respectieve taken uit te voeren. Een specifieke bedrijfsbehoefte doet zich voor wanneer het volume van deze wijzigingen hoog is en de berichten complex zijn, waardoor traditionele punt-naar-punt integraties omslachtig en moeilijk te onderhouden zijn. Het tot stand brengen van fragiele, aangepaste verbindingen voor elke afzonderlijke afhankelijke toepassing leidt tot technische schulden en belemmert het vermogen van de organisatie om snel op te schalen. Een robuuste integratiebenadering is nodig om deze frequente gegevenssynchronisaties te beheren zonder het bronsysteem rechtstreeks aan elk verbruikend systeem te koppelen.

Het diagram hieronder toont een typisch publicatie-/abonneerpatroon met meerdere uitgevers en abonnees die gegevens delen via een eventbus. Dit basispatroon vormt de basis voor de meer specifieke patronen die in de rest van deze handleiding te vinden zijn. Enkele belangrijke kenmerken van dit patroon zijn:

• Er is geen directe verbinding tussen uitgevers en abonnees. Uitgevers verzenden gewoon berichten naar een eventbus, die ze rondstuurt naar elk ander systeem dat voor ze wil luisteren.

• Hetzelfde systeem kan zowel uitgever als abonnee zijn.

• Systemen kunnen meerdere typen events publiceren of zich erop abonneren.

• Zoals bij alle patronen in deze handleiding valt het publicatie-/abonneerpatroon in een algemene categorie integratiepatronen die bekend staat als aanroepen van externe procedures (RPI) of gewoon "branden en vergeten".

Wanneer een organisatie onmiddellijke updates moet verzenden naar een groot aantal clienttoepassingen, zoals pushkennisgevingen of sms-berichten naar mobiele apparaten, wordt het traditionele proces van het maken van unieke transmissies voor elke afzonderlijke ontvanger al snel een knelpunt in de schaalbaarheid. De kernbehoefte is in dit geval de snelle, hoogwaardige distributie van één informatie—zoals een accountwaarschuwing of een kritieke kennisgeving van servicewijziging—naar verschillende eindpunttoepassingen tegelijk. Een gestroomlijnde aanpak om aan deze vereiste te voldoen, omvat het routeren van alle berichten via één wachtrij, die fungeert als het centrale punt van eventinformatie voor alle verbruikende systemen. Deze benadering verbetert de prestaties door het elimineren van de noodzaak om veel afzonderlijke berichtkopieën te beheren.

Met het fanout-patroon worden berichten geleverd aan een of meer bestemmingen (d.w.z. luisterende cliënten of abonnees) via één berichtenwachtrij. Abonnees halen hetzelfde bericht op uit de wachtrij, in plaats van hun eigen unieke exemplaar. (Hoewel dit de prestaties verbetert, kan het ook moeilijker zijn om te controleren of een bepaalde abonnee het bericht al dan niet heeft ontvangen.)

Sommige eventscenario's worden gekenmerkt door een aanzienlijke toename van het berichtenvolume dat de capaciteit van synchronisatie- en transformatieprocessen dreigt te overbelasten, of door complexe logica met meerdere stappen die vereist is voor het verwerken en transformeren van eventgegevens.

Enkele voorbeelden zijn:

• Seizoensvolumepieken: Er kunnen pieken in volume zijn die online retailers ervaren wanneer een selectie van hun producten "in het seizoen" is. Wanneer grote aantallen klanten tegelijkertijd aankopen doen, kan het aantal gegenereerde events tijdelijk de capaciteit van synchronisatie- en transformatieprocessen overschrijden. Zie Goed ontworpen - Gegevensverwerking voor meer informatie.

• Case- of claimbeheer: Servicegebaseerde bedrijven kunnen tijdens uitval een stijging van het aantal cases of claims ervaren.

• Complexe gegevenstransformaties: Organisaties die complexe logica vereisen om berichten te transformeren, maken zich vaak zorgen over events die sneller worden gegenereerd dan kunnen worden getransformeerd.

Dit patroon is gericht op de uitdaging om berichten sneller te genereren dan ze kunnen worden getransformeerd. Het zorgt ervoor dat grote volumes berichten en vereiste gegevensmanipulaties betrouwbaar kunnen worden afgehandeld, waarbij een streaming berichtenplatform wordt geïntegreerd en berichtverwerkingslogica wordt gesegmenteerd in speciale componenten.

Het patroon Doorgegeven berichten werkt door berichtverwerkingslogica te segmenteren in meerdere componenten:

• Eén component handelt de berichtroutering af en bepaalt de vereiste transformaties en de eindbestemming.

• Een afzonderlijke set componenten verwerkt verschillende lagen van berichttransformatie (bijvoorbeeld veldtoewijzingen, objectrelaties, enzovoort).

• De laatste component schrijft het definitieve, gewijzigde bericht uit.

Sommige producenten genereren een continue stroom van events. Een veelvoorkomend voorbeeld is mediastreaming, waarbij gebruikersinteracties optreden die zich van nature voordoen als afzonderlijke events. Meerdere systemen moeten gelijktijdig op hetzelfde gebruikersgedrag reageren zonder de kernervaring van streaming te blokkeren.

Denk aan de events voor een muziekstreamingplatform. Dit kunnen zijn:

• Gestarte/onderbroken/overgeslagen events bijhouden

• Events van luistersessies met tijdstempels

• Events voor het maken/wijzigen van afspeellijsten

• Events voor sociaal delen

• Downloaden voor offline luisteren

In het Streaming-patroon hebben abonnees toegang tot elke eventstroom en verwerken ze de events in de exacte volgorde waarin ze worden ontvangen. Unieke kopieën van elke berichtenstroom worden naar elke abonnee verzonden, waardoor het mogelijk is om abonneespecifieke inhoud te leveren en te bepalen welke abonnees welke stromen ontvangen.

Om een stroom logisch te maken, moeten alle events en de bijbehorende berichten in de juiste volgorde staan. Als u de gegevens in een stroom uit verschillende systemen haalt, moet u extra orderlogica opnemen als onderdeel van het ontwerpproces.

Gebruikscases in wachtrijen zijn alomtegenwoordig. Voorbeelden omvatten:

• Internetverbinding van lage kwaliteit: Field Service-organisaties of andere organisaties waar teams met mobiele apparaten moeten werken in gebieden met internettoegang van lage kwaliteit of intermitterende internettoegang, profiteren van wachtrijen omdat de toepassingen op deze apparaten verbinding kunnen maken met hun wachtrijen en alle relevante berichten kunnen ophalen wanneer de connectiviteit is hersteld.

• Berichtbuffering: Wanneer het berichtvolume af en toe de verwerkingscapaciteit van een abonnee overschrijdt en een grotere latentie geen extra problemen veroorzaakt, kunnen wachtrijen een buffer zijn om overtollige berichten op te slaan en gegevensverlies te voorkomen.

• Transportbeheer: Logistieke organisaties die hun wagenpark moeten bewaken, kunnen dit patroon gebruiken om de routes die elk voertuig aflegt, vrijwel in realtime weer te geven en ervoor te zorgen dat chauffeurs zo efficiënt mogelijk zijn.

• IoT-apparaten: Fabrikanten gebruiken vaak systemen die snelle gegevensstromen genereren, en deze stromen kunnen downstream gevolgen hebben voor extra systemen. Dit patroon kan worden gebruikt om reeksen gebeurtenissen te identificeren die menselijke tussenkomst vereisen voordat catastrofale mislukkingen over meerdere systemen optreden.

In het patroon Wachtrij verzenden producenten berichten naar wachtrijen, die de berichten vasthouden totdat abonnees ze ophalen. De meeste berichtwachtrijen volgen first-in, first-out (FIFO) volgorde en verwijderen elk bericht nadat het is opgehaald. Elke abonnee heeft een unieke wachtrij, die extra set-upstappen vereist, maar het mogelijk maakt om levering te garanderen en te identificeren welke abonnees welke berichten hebben ontvangen.

Vanwege de asynchrone aard van het patroon Queuing kan er een lange vertraging zijn tussen het toevoegen van een bericht aan een wachtrij en het ophalen van dat bericht. Wachtrijen vereisen geheugen of opslagruimte om hun berichten op te slaan, waardoor ze niet onbeperkt kunnen groeien. Dit betekent dat een abonnee die voor onbepaalde tijd offline is, een fout kan veroorzaken als er voldoende berichten in de wachtrij worden opgebouwd. Berichtbuffering kan hetzelfde effect hebben als de verwerkingstijden van abonnees te lang worden, waardoor grote aantallen berichten in hun wachtrijen worden opgebouwd. Als u deze risico's wilt beperken, voert u een grondige analyse uit van de opslagvereisten voor alle berichtwachtrijen en ontwerpt u indien nodig processen die wachtrijen opschonen en uitschakelen als berichten niet binnen een bepaalde hoeveelheid tijd worden opgehaald of wanneer ze een vooraf bepaald volume bereiken.

Zelfs als u er volledig van overtuigd bent dat een eventgestuurde architectuur geschikt is voor uw organisatie, begint u mogelijk met een landschap dat al een groot aantal punt-naar-punt integraties heeft. Financiering krijgen voor een project om al uw integraties in één keer te vervangen kan moeilijk zijn, en het is mogelijk dat het niet eens mogelijk is om een eventgestuurde architectuur rechtstreeks met sommige verouderde systemen te gebruiken. In deze scenario's kunt u een incrementele benadering kiezen voor het migreren naar een meer losgekoppelde architectuur door eerst de meest bedrijfskritieke toepassingen te converteren en vervolgens andere systemen te converteren wanneer ze worden bijgewerkt of vervangen in toekomstige projecten. Deze benadering maakt het gemakkelijk om nieuwe toepassingen toe te voegen aan de eventbus en zorgt ervoor dat uw algehele IT-landschap schaalbaar en veerkrachtig blijft naarmate systemen in de loop van de tijd worden toegevoegd.

Als architecten weten we dat elke architectuur nadelen heeft. Een event-gestuurde architectuur is geen uitzondering. Hoewel een landschap vol los gekoppelde systemen zeer schaalbaar en veerkrachtig is, zijn er ook enkele nadelen om te overwegen:

• Algemene integratiestrategie: Ongeacht de tools en patronen die u besluit te gebruiken, is het belangrijk om eerst een strategie te ontwikkelen voor de manier waarop gegevens worden gedeeld tussen de verschillende systemen in het landschap van uw organisatie. Deze strategie moet de doelen van uw organisatie voor de gegevens omvatten, de manier waarop gegevens kunnen worden gedeeld en patronen kunnen worden gebruikt, alsmede gegevensbronnen, doelen, structuren en eigendoms- en toegangsvereisten.

• Ondersteuning voor oudere systemen: Uw organisatie heeft mogelijk verouderde systemen die gewoon geen ondersteuning bieden voor eventgestuurde architectuurpatronen. Hoewel het mogelijk is om oplossingen te vinden (bijvoorbeeld met een proces dat als doorgeefluik fungeert door zich te abonneren op events en de uitvoer vervolgens via een andere manier van gegevensoverdracht naar het doelsysteem te verzenden), wilt u in dit geval wellicht andere integratiemethoden overwegen.

• Structuurwijzigingen in berichten: Zodra de structuur van het initiële bericht is gedefinieerd en overeengekomen tussen uitgevers en abonnees, kan het moeilijk zijn om dit te wijzigen, vooral als de abonnees extern zijn. Er zijn verschillende manieren om dit probleem aan te pakken. U kunt eindpunten met versiebeheer gebruiken, maar zorg ervoor dat u voor elke versie een duidelijke levenscyclus definieert en communiceert, zodat uw ontwikkelaars niet te veel versies tegelijkertijd hoeven te onderhouden. Als Apache Kafka op Heroku deel uitmaakt van uw landschap, kunt u ook een schemaregister of soortgelijke tool overwegen, maar zorg ervoor dat de andere systemen in uw landschap het ook ondersteunen (en gebruiken).

• Gebrek aan zichtbaarheid tussen uitgevers en abonnees: In de meeste eventgestuurde architectuurpatronen zijn de uitgevers zich niet bewust van de status van hun abonnees. Dus als een uitgever een kritiek bericht verzendt terwijl alle abonnees offline zijn, wordt het bericht mogelijk nooit afgeleverd. U kunt dit probleem oplossen door de functionaliteit voor opnieuw afspelen te gebruiken of redundante abonnees toe te voegen die op afzonderlijke servers worden uitgevoerd voor alle kritieke berichten.

• Knelpunten in prestaties: Naarmate een eventgestuurde architectuur opschaalt, kan de eventbus een knelpunt worden voor het bezorgen van berichten als deze wordt overbelast met te veel uitgevers die tegelijkertijd proberen om te veel abonnees een bericht te sturen. U kunt dit oplossen door meer geheugen en verwerkingsresources toe te wijzen aan de eventbus of door meerdere eventbussen te gebruiken om verschillende typen berichten parallel te verwerken.

Overweeg voordat u een eventgestuurde architectuur implementeert of u er überhaupt een moet gebruiken. De vorige sectie beschrijft veelvoorkomende bedrijfsscenario's die goed passen bij elk eventgestuurd architectuurpatroon. U kunt ook meer lezen in Goed Architectuur - Interoperabiliteit. Bekijk Uitdagingen om te overwegen bij het implementeren van Eventgestuurde architecturen om te bepalen of de patronen die u in gedachten hebt, het beste aansluiten op uw specifieke gebruikscases.

Hoewel de meeste scenario's die in deze handleiding worden behandeld integraties omvatten, kunnen eventgestuurde architecturen ook worden gebruikt om berichten binnen één Salesforce-organisatie te verzenden, bijvoorbeeld door middel van platformevents. Zorg ervoor dat u rekening houdt met alle van toepassing zijnde eventtoewijzingslimieten bij het ontwerpen van processen die platformevents gebruiken als een intern berichtenverkeerssysteem.

Antipatronen rond eventgestuurde architecturen ontstaan vaak door events te gebruiken als tussenoplossing voor interne communicatie binnen een Salesforce-organisatie. Veel voorkomende antipatronen zijn:

• Events publiceren vanuit Apex triggers gekoppeld aan hetzelfde eventobject: Dit resulteert in een oneindige triggerlus.

• Events publiceren vanuit Apex voordat een DML-transactie is voltooid: Als een transactie mislukt en wordt teruggedraaid, worden gepubliceerde events die de werking Onmiddellijk publiceren hebben, niet opgenomen in de werking van terugdraaien.

• Events publiceren in Flow om daaropvolgende automatisering te organiseren: De beste manier om logica voor meerdere automatiseringen te coördineren is het gebruik van substromen of Flow Orchestrator.

• Run-time afhankelijkheden maken: Publiceer geen events om de communicatie tussen pakketten te vergemakkelijken zonder de juiste stappen te ondernemen om run-time afhankelijkheden te elimineren.

• Onnodig grote payloads: Wanneer u verzoeken doet, kunt u het beste de kleinst mogelijke hoeveelheid gegevens in de payload verzenden en ontvangen. Elke actie van een gebruiker kan potentieel meerdere verzoeken opleveren en het is belangrijk dat deze efficiënt worden verwerkt. Het verzenden van meer gegevens dan nodig is, kan bijdragen aan traag transport en een langere verwerkingstijd.

• Niet-selectieve afhandeling van toepassingsevents: Wanneer er meerdere componenten zijn die luisteren naar een toepassingsevent, moeten ontwikkelaars ervoor zorgen dat de eventhandler alleen wordt uitgevoerd wanneer dit daadwerkelijk gewenst en nuttig is. Zo kunnen componenten in de Lightning Console die zijn opgenomen in tabbladen waarop geen focus is, nog steeds luisteren, ook al zijn ze niet zichtbaar. Een ontwikkelaar kan verschillende technieken gebruiken, zoals het gebruik van een achtergronditem van een hulpprogramma als enige luisteraar of het aanroepen van getEnclosingTabId() om te bepalen of dit exemplaar van de component is ingesloten binnen het tabblad Focus om ervoor te zorgen dat elke event alleen wordt afgehandeld wanneer deze is bedoeld.

• Gebruik van Platform-events publiceert gedrag onjuist: Platform-events hebben twee publicatiewerkingen: Onmiddellijk publiceren en Publiceren na verbintenis. Het kan handig zijn om real-time platformevents te gebruiken voor gebruikscases zoals Vastleggen, waarbij u de vastleggingsevent wilt publiceren, ongeacht of de transactie slaagt en wordt uitgevoerd. Gebruik Onmiddellijk publiceren echter zeer voorzichtig met realtime platformevents. Events kunnen worden verbruikt door abonnees binnen dezelfde transactie en rijvergrendelingen of andere raceomstandigheden veroorzaken.

Bij het implementeren van een eventgestuurde architectuur is een van de sleutels tot succes het instellen van standaarden voor de manier waarop de events zelf worden ontworpen. De details variëren afhankelijk van de gebruikscases van uw organisatie, maar hier zijn enkele algemene richtlijnen:

• Bepaal de optimale structuur voor uw eventpayloads. Hoewel kleinere berichtgroottes de verwerkingstijden verkorten, kan het bombarderen van abonnees met grote aantallen berichten leiden tot bottlenecks in de prestaties. Mogelijk moet u uw payloadgrootten en -structuren herhalen om de juiste balans te vinden. MuleSoft en soortgelijke ESB-tools bieden de mogelijkheid om aangepaste payloads te ontwerpen in de berichten die aan uw events zijn gekoppeld, wat u kan helpen gegevensstructuren te visualiseren om de prestaties aan de kant van de abonnee te verbeteren. (Zie Goed ontworpen - API-beheer voor meer informatie.)

• Denk end-to-end na over uw processen. Zorg ervoor dat u geen "eindeloze lus"-scenario's maakt, die moeilijk kunnen worden opgespoord zodra de integraties zijn geïmplementeerd. Een voorbeeld hiervan zijn twee systemen die events publiceren wanneer records worden bijgewerkt, terwijl ook naar elkaars events wordt geluisterd, waardoor extra gepubliceerde events worden geactiveerd wanneer ze worden verwerkt.

  U kunt dit type anti-patroon corrigeren door logica toe te voegen aan beide systemen die ervoor zorgt dat wijzigingen die worden aangebracht als gevolg van het verbruik van een event, niet leiden tot het publiceren van een nieuwe event. Zorg er ook voor dat u al uw events, de gekoppelde triggers ervan en de downstreamsystemen die mogelijk worden beïnvloed, documenteert. Gebruik deze documentatie als naslagwerk tijdens ontwerpsessies om eindeloze lussen en soortgelijke scenario's zo vroeg mogelijk te ontdekken. (Zie Goed ontworpen - Procesontwerp voor meer informatie.)

• Gebruik gangbare naamgevingsconventies voor alle systemen. Consistente naamgevingsconventies zijn een best practice voor alle softwareontwikkeling, inclusief eventgestuurde architecturen. Neem de tijd om een set standaarden te documenteren voor eventnamen, structuren, gekoppelde objecten en foutafhandelingsprocessen om consistentie tussen systemen te waarborgen. (Zie Goed ontworpen - ontwerpnormen voor meer informatie.)