Hendelsesdrevet arkitektur (EDA) er en måte å bygge programvare på der deler av et system kommuniserer ved å melde fra om at noe har skjedd, i stedet for å kalle hverandre direkte. Én komponent publiserer en hendelse, for eksempel «faktura betalt» eller «kontrakt signert». Alle andre komponenter som er interessert, reagerer på den. Ingen av sidene trenger å vite at den andre finnes.

For et SaaS-selskap har dette betydning langt utover utviklingsmiljøet. Den samme ideen ligger bak rene overleveringer mellom CRM og økonomi, pålitelig automatisering og AI-agenter som handler på oppdaterte data. Denne guiden forklarer hvordan EDA fungerer, hvordan en hendelsesbuss skiller seg fra en kø, hvordan du unngår de vanligste feilene, og hvor den hører hjemme og ikke hører hjemme.

Kort fortalt

Innholdsfortegnelse

Hva hendelsesdrevet arkitektur er

Microsofts arkitekturveiledning beskriver stilen som hendelsesprodusenter som genererer en strøm av hendelser, hendelseskonsumenter som lytter etter dem, og hendelseskanaler som frakter hendelser fra den ene til den andre. Denne modellen i tre deler er hele ideen. Alt annet er detaljer om hvor pålitelig og hvor raskt kanalen fungerer.

Motsatsen er forespørsel/svar. I et design med forespørsel/svar kaller faktureringstjenesten din CRM-systemet og venter på svar. Hvis CRM-systemet er tregt eller nede, står faktureringen fast. I et hendelsesdrevet design publiserer faktureringen «betaling mottatt» og går videre. CRM-systemet, inntektsrapporten og dashbordet for customer success plukker hver for seg opp hendelsen når de er klare.

To egenskaper følger av dette:

Hva som regnes som en hendelse

En hendelse er en påstand om et faktum i fortid. Red Hat beskriver den som en uforanderlig registrering av at noe har skjedd, ofte med et tidsstempel som bevarer rekkefølgen i forhold til systemet som produserte den. Du redigerer ikke en hendelse i etterkant. Hvis noe endrer seg, registrerer en ny hendelse endringen.

AWS påpeker at hendelser kan være en tilstandsendring eller en oppdatering, og de kan enten bære tilstand eller være identifikatorer. To eksempler:

Stil Eksempel Hva konsumenten får
Hendelse som bærer tilstand Abonnement oppgradert, med plan, pris, ikrafttredelsesdato og konto-ID Alt som trengs for å handle uten et nytt oppslag
Hendelse som identifikator Ordre sendt, kun med ordre-ID Et signal. Konsumenten henter detaljene fra kildesystemet

Den første er praktisk, men binder konsumentene til hendelsens form. Den andre holder hendelsene små, men sender konsumentene tilbake til kildesystemet, noe som reiser spørsmålet om hvilket system som er autoritativt. Vi kommer tilbake til det nedenfor, for det er her de fleste driftsløsninger i SaaS sliter.

En kommando er ikke en hendelse. «Send fakturaen» er en instruks til en bestemt mottaker. «Faktura sendt» er et faktum som alle kan reagere på. Å blande de to er en vanlig designfeil, og den bygger i det stille opp igjen den tette koblingen du ville bli kvitt.

Slik fungerer et hendelsesdrevet system, steg for steg

Google Clouds dokumentasjon beskriver flyten: produsenter genererer hendelser, en ruter eller broker tar imot og filtrerer dem, og sender dem deretter videre til konsumenter basert på abonnementer eller triggere. I praksis:

  1. Noe skjer. En avtale flyttes til «Closed Won» i CRM-systemet.
  2. Produsenten publiserer en hendelse. Den angir faktum og posten det gjelder.
  3. Brokeren ruter den. Den filtrerer hendelsen og leverer den til hver abonnent.
  4. Konsumentene reagerer uavhengig av hverandre. Økonomi oppretter et fakturautkast. Kundesuksess åpner en oppstartsplan. En provisjoneringsprosess forbereder tilgang.
  5. Hver konsument bekrefter. Brokeren vet at hendelsen er håndtert og kan prøve på nytt hvis den ikke ble det.

IBM beskriver det samme mønsteret som publisering, innhenting, behandling og lagring av hendelser, og peker på at verdien av en hendelse kan endre seg over tid. En «ny lead»-hendelse er verdt å handle på i løpet av minutter. Et år senere er den for det meste nyttig for analyse.

Hendelsesdrevet arkitektur og mikrotjenester

Folk behandler ofte disse som det samme. Det er de ikke. Mikrotjenester beskriver hvordan du deler en applikasjon opp i små, uavhengig utrullede tjenester. EDA beskriver hvordan disse tjenestene kommuniserer. Du kan ha mikrotjenester som kaller hverandre synkront, og du kan ha en monolitt som publiserer hendelser internt.

De to fungerer godt sammen. Googles veiledning peker på at mikrotjenester kan reagere asynkront på hendelser og bare trenger å kjenne hendelsesformatet, ikke hverandres forretningslogikk. Det felles formatet er kontrakten. Alt bak det kan endres.

Microsofts dokumentasjon beskriver det typiske mønsteret som mikrotjenester som publiserer en hendelse når noe bemerkelsesverdig skjer, mens andre mikrotjenester abonnerer.

Hendelsesbuss, kø og strøm

Disse tre begrepene skaper mest forvirring, og valget endrer hvordan systemet ditt oppfører seg.

Hendelsesbuss (publiser/abonner). En hendelsesbuss er en mekanisme der utgivere kunngjør hendelser og abonnenter mottar dem. Microsoft forklarer at den kan implementeres på meldingsinfrastruktur som en kø eller en tjenestebuss som støtter asynkron publiser/abonner. Altså kan en kø være en av byggeklossene i en buss. Bussen er intensjonen. Køen er én måte å realisere den på.

Kø. En kø holder meldinger til en arbeider tar dem. Hver melding håndteres normalt av én konsument. Køer er riktig verktøy for å fordele arbeid på flere arbeidere og for å absorbere belastningstopper. Azures integrasjonsveiledning nevner å legge meldinger i kø når en backend er utilgjengelig som én grunn til å bruke en broker.

Hendelsesstrøm. Azure skiller publiser/abonner fra strømming. Ved publiser/abonner lagres ikke en hendelse i en varig logg når den er mottatt, så nye abonnenter ser ikke tidligere hendelser. Ved strømming skrives hendelser til en logg som er varig og strengt ordnet innenfor en partisjon, og klienter leser fra loggen og kan koble seg på når som helst og spille av hendelser på nytt.

Kø Publiser/abonner-buss Hendelsesstrøm
Levering Én konsument per melding Hver abonnent Hvilken som helst leser, fra et hvilket som helst punkt
Tidligere hendelser Fjernes etter behandling Ikke tilgjengelig for nye abonnenter Lagres og kan spilles av på nytt
Typisk bruk Arbeidsfordeling, buffering Varsling av flere systemer Historikk, analyse, gjenoppbygging av tilstand

En praktisk regel: hvis flere systemer må reagere på det samme faktumet, bruk publiser/abonner. Hvis én arbeider skal gjøre en jobb, bruk en kø. Hvis du trenger historikk eller muligheten til å bygge opp et nedstrøms system på nytt, bruk en strøm. Red Hat legger til at det finnes ingen løsning som passer for alt, så velg teknologi etter hendelsestype.

Er Kafka en hendelsesdrevet arkitektur?

Nei. Kafka er en teknologi du kan bruke til å bygge en. Dokumentasjonen til Apache Kafka beskriver den som en plattform for hendelsesstrømming: innhenting av hendelser i sanntid, varig lagring, behandling og ruting til andre systemer. Det gjør den til en hendelsesstrøm i tabellen ovenfor.

En arkitektur er et sett med designbeslutninger: hva hendelsene er, hvem som eier dem, hvordan konsumenter isoleres og hva som skjer ved feil. Du kan ta disse beslutningene og kjøre løsningen på en administrert skybuss, en køtjeneste eller Kafka. Du kan også kjøre Kafka og likevel ha et tett koblet system hvis hver tjeneste avhenger av en annen tjenestes interne hendelser. Velg verktøyet etter at du har definert hendelsene og volumet du faktisk forventer.

Hendelsesdrevet integrasjon og automatisering

Her blir EDA relevant for driftsledere, ikke bare for utviklere.

Integrasjon

De fleste SaaS-selskaper kobler sammen CRM-, fakturerings-, support- og produktdata med punkt-til-punkt-synkroniseringer. Hvert nytt verktøy legger til en ny kobling som må vedlikeholdes. Azure anbefaler asynkron kommunikasjon via en meldingsbroker i stedet for direkte synkrone kall, av fire grunner som listes opp: frikobling av applikasjoner, kringkasting til flere konsumenter, pålitelig sporing av langvarige arbeidsflyter og køing av meldinger når en backend er utilgjengelig.

Fordelen viser seg når du legger til et system. Med en publiser/abonner-tjeneste kan nye abonnenter legges til uten å oppdatere avsenderen. Å legge til et nytt analyseverktøy krever ingen endring i CRM-systemet ditt.

Automatisering

Hendelsesdrevet automatisering betyr at en forretningsprosess starter fordi noe skjedde, ikke fordi noen klikket på en knapp eller en nattlig jobb kjørte. ServiceNows flytguide gir en praktisk metode: identifiser triggeren, planlegg logikken, velg handlingene og identifiser gjenbrukbar logikk. Den anbefaler også å holde flyter fokuserte og bruke ett verb per handling.

Når en prosess spenner over flere tjenester, påpeker Microsoft at hendelsesdrevne systemer ofte bruker koreografi- og saga-orkestreringsmønstre for å koordinere flyten. I koreografi reagerer hver tjeneste på hendelser og sender ut sine egne. I orkestrering forteller en koordinator hvert steg hva det skal gjøre og følger hele prosessen. For et første prosjekt er en orkestrert flyt vanligvis lettere å lese og revidere.

Et enkelt SaaS-eksempel:

Beste praksis og vanlige utfordringer

Azure viser de viktigste utfordringene: eventual consistency, asynkron feilhåndtering, datatap, observerbarhet og testing, for mange eller for sammenslåtte hendelser, og skjemautvikling. Hver av dem har en tilsvarende praksis.

  1. Planlegg for eventual consistency. Systemene vil en kort stund være uenige. Bestem hvilket system som er autoritativt for hvert faktum, og la de andre følge det.
  2. Legg til en dedikert feilhåndterer. Mislykkede hendelser trenger et sted å havne og noen som ser på dem.
  3. Behold hendelser til mottak er bekreftet. Dette beskytter mot datatap når en mottaker er nede.
  4. Bruk korrelasjons-ID-er. Én ID som følger hvert steg gjør at du kan spore én enkelt kundehandling på tvers av systemer.
  5. Finn riktig granularitet på hendelsene. Én hendelse per feltendring skaper støy. Én gigantisk hendelse for alt skaper tett kobling på nytt.
  6. Versjonér skjemaer tidlig. Hendelsesformater vil endre seg. Bestem hvordan før du har tjue mottakere.

I tillegg vil vi foreslå tre driftsvaner: gi hendelser navn i fortid, gi hver hendelsestype én eier, og skriv ned hvilke mottakere som er avhengige av den.

Hvor hendelsesdrevet design ikke hører hjemme

EDA er ikke svaret på alle problemer. Vær tydelig på begrensningene før du forplikter deg:

Den samme logikken gjelder for AI. En AI-assistent som leser fra og handler i systemene dine, er både mottaker og produsent av hendelser. Hvis den leser inkonsistente data eller handler uten en tillatelsesgrense, har du en raskere måte å lage feil på.

Der dette møter AI-agenter og regelverk

AI-agenter som henter data (spørre, rapportere, slå opp) og sender data (oppdatere en post, utløse en prosess, gi tilgang) oppfører seg som deltakere i et hendelsesdrevet system. De trenger en pålitelig kilde å lese fra, et tydelig sett med handlinger de har lov til å utføre, godkjenning for sensitive steg og en logg over hva de har gjort. En hendelseslogg er et naturlig sted for denne loggen.

Operatør som gjennomgår en hendelseslogg for en AI-agent

For europeiske selskaper påvirker GDPR, NIS2 og EU AI Act hvordan slike systemer utformes. Generelt handler de om hvilke personopplysninger som flyter gjennom hendelser, hvordan sikkerhet og hendelseshåndtering er organisert, og hvordan AI-systemer styres og dokumenteres. Behandle dem som designkrav fra starten, og innhent juridisk rådgivning om hvordan de gjelder i ditt konkrete tilfelle. Ingen arkitekturvalg alene gjør et system i samsvar med regelverket.

Vårt perspektiv

De fleste SaaS-selskaper vi snakker med, har ikke et hendelsesproblem. De har et eierskapsproblem. Flere team bruker AI, flere verktøy har hver sin versjon av kunden, og ingen er ansvarlig for hvilken versjon som er riktig.

Derfor jobber vi i en fast rekkefølge. Først datafundamentet: CRM- og økonomidata som den avtalte sannhetskilden. Deretter AI-laget, som kobler disse dataene til assistenten teamet ditt allerede bruker. Så avdelingsagenter for Finance, Sales og Customer Success. Hendelser er nyttige i alle tre lagene, men de hjelper først når faktaene de bærer, er avtalt.

Vi innfører også én prosess om gangen, og starter med den dyreste. En fornyelsesprosess eller en overlevering fra faktura til betaling er et bedre første hendelsesdrevet prosjekt enn en ombygging av hele selskapet. Du ser resultatet, folkene dine lærer mønsteret, og neste prosess blir billigere.

Fordi vi driver operasjoner i tillegg til å utforme systemer, bryr vi oss om de kjedelige delene: tillatelser, godkjenninger, revisjonsspor og en overlevering der du eier koden, dokumentasjonen og infrastrukturen.

Claus Nielsen

Kom i gang i ditt eget selskap

Du trenger ikke velge meldingsmegler (broker) først. Start med disse spørsmålene:

  1. Hvilken prosess koster deg mest i manuelt arbeid, forsinkelser eller feil?
  2. Hvilke to eller tre hendelser starter den (for eksempel avtale vunnet, faktura forfalt, fornyelse nærmer seg)?
  3. Hvilket system er sannhetskilden for dataene i disse hendelsene?
  4. Hvem eier hver hendelsesdefinisjon?
  5. Hvilke steg krever godkjenning av et menneske?

Hvis du ikke kan svare på det tredje spørsmålet, kommer datafundamentet først. Hvis du kan, vil en liten pilot på én prosess vise deg om en hendelsesdrevet tilnærming lønner seg.

Slik kan vi hjelpe

Hvis teamet ditt bruker AI, men ingen eier det, kan vi hjelpe deg med å avgjøre hvor det lønner seg, og bygge det i riktig rekkefølge. Vår AI Readiness Assessment er tilgjengelig fra €4,500 og ser på data, systemer og prosesser før noe bygges. Hvis du ønsker løpende ledelse, starter Fractional Chief AI Officer-avtalen fra €1,500 per måned.

Byggeoppdrag prises til 30% av en førsteårsbesparelse som er målt og dokumentert, eller til en fastpris avtalt før arbeidet starter. Du kan også bestille en gratis oppstartssamtale på 30 minutter via nettstedet vårt. Våre AI-agenter for Finance, Sales og Customer Success viser hvordan avdelingslaget ser ut når fundamentet er på plass.

FAQ

Hva er hendelsesdrevet arkitektur i enkle ord?

Det er en utforming der programvarekomponenter melder fra om at noe har skjedd, og andre komponenter reagerer. Avsenderen vet ikke hvem som lytter. Det gjør at du kan legge til eller endre systemer uten å skrive om de som produserer hendelsene.

Hva er forskjellen mellom en hendelsesbuss og en meldingskø?

En kø leverer vanligvis hver melding til én arbeider. En hendelsesbuss leverer hver hendelse til alle abonnenter. En buss kan bygges på køinfrastruktur, så forskjellen ligger i hensikten og leveringsmønsteret, ikke alltid i produktet.

Er hendelsesdrevet arkitektur det samme som mikrotjenester?

Nei. Mikrotjenester handler om hvordan en applikasjon deles opp i tjenester. Hendelsesdrevet arkitektur handler om hvordan delene kommuniserer. De brukes ofte sammen, men hver av dem kan finnes uten den andre.

Når bør et SaaS-selskap bruke hendelsesdrevet automatisering?

Bruk det når en forretningsprosess skal starte fra et faktum, for eksempel en lukket avtale eller en forestående fornyelse, og flere team eller systemer må reagere. Start med én kostbar prosess, og sørg for at kildedataene er avklart først.

Kilder