Event Storming er et workshop-format oppfunnet av Alberto Brandolini som muliggjør massiv læring om komplekse forretningsområder og fremmer samarbeid mellom forskjellige disipliner og på tvers av team.
Metoden brukes ofte av utviklere og forretningsfolk for å samarbeide om å skape en felles forståelse av forretningsflyt.
I denne artikkelen vil jeg utforske bruken av Event Storming som en praksis for å identifisere korrekte domenekomponenter i Domain Driven Design (DDD). Det vil hjelpe å se forretningen fra fugleperspektiv.
Flere faser
Når vi bruker DDD er vi på en reise for å lære dypt om hvordan forretningen fungerer, og deretter modellere programvaren/kode basert på vår læring. Det er viktig å tilpasse programvarens domenemodeller til det domenet ekspertene hadde i tankene.
Event Storming er en prosess for å lære og eksperimentere og modellere i fellesskap hele tiden. Jeg liker å tenke på det som en måte å iterativt lære fra både kjente og ukjente domener.
Event Storming er en iterativ metode som gjennomføres i flere faser:
- I den første fasen identifiseres de viktigste hendelsene i forretningsprosessen.
- I den andre fasen identifiseres de ulike aktørene som er involvert i hendelsene.
- I den tredje fasen identifiseres de ressursene som er nødvendige for å håndtere hendelsene.
Event Storming kan gjennomføres på en rekke måter. En vanlig måte er å bruke en stor vegg med mange fargerike klistrelapper. Hver klistrelapper representerer en hendelse, aktør eller ressurs.
Både forretning og teknisk
Det er viktig at både forretningsfolk og tekniske folk er involvert i Event Storming.
Forretningsfolk kan bidra med sin innsikt i hvordan forretningsprosessen fungerer, mens tekniske folk kan bidra med sin innsikt i hvordan systemene kan implementeres.
Event Storming i DDD er som et samtaleverktøy mellom ulike profesjoner. Alle kommer til å få ny innsikt.
I noen tilfeller kan utviklere sitte alene og tegne mens de har en samtale med domeneeksperter. Dette kan være en effektiv måte å samle inn informasjon fra ekspertene uten å forstyrre den naturlige strømmen av samtalen. Metoden kan bidra til å skape en felles forståelse av forretningsflyten og den kan også bidra til å identifisere forbedringsmuligheter.
Et eksempel
Dette er et forenklet eksempel, brukt for å forklare bruken av Event Storming for utviklere.
Det vi skal bygge skal kunne:
💡 Scenario 1: Søke etter flybillett
- GITT flyselskapets nettside
- SÅ Søker du etter en destinasjon
- DA Returneres en liste med resultater
💡 Scenario 2: Velge flybillett
- GITT liste over tilgjengelige flyturer
- SÅ Velger du en tur
- OG velger kjøp
💡 Scenario 3: Kjøpe flybillett
- GITT en valgt flyreise
- SÅ Legger du til kredittkortinformasjon
- OG Kjøper flybillett
💡 Scenario 4: Bekreftelse
- GITT et vellykket kjøp av flybillett
- SÅ får du en e-postbekreftelse på kjøpet
Start alltid med hendelsene
En domenehendelse er en registrering av en forretningshandling innenfor en Bounded Context.
Slike hendelser bør representere verb i fortid, for eksempel CustomerMoved, PackageShipped eller BankTransactionRecorded. De representerer handlinger som har funnet sted i fortiden. Det første steget er å skrive potensielle hendelser innenfor vårt domene ved hjelp av oransje klistrelapper.
Her er en oversikt over domenehendelsene i vår forretning:
Identifiser årsaken til hendelsen
Domeneeksperter bør kunne vite hvorfor en hendelse skjer. Disse kan kalles en kommando som kan farges blått:
De grønne klistrelappene kalles views. De grønne klistrelappene er visningen i din modell. Det kan være en React-side eller en annen visuell representasjon.
(Invariants) er de gule klistrelappene som er vist nedenfor. Mye av logikken mellom en kommando (blå) og en hendelse (oransje) er der i de gule klistrelappene.
Systemet vårt vil fungere på mange kommandoer her. Bruk Domain-Driven Design-teknikker eller den heksagonale arkitekturen for å implementere det i kode. Områder som inneholder få eller ingen gule lapper er klare og enkle å implementere i kode.
Definere grenser
Når du har fullført defineringen av en del av designfasen, er du klar til å tegne grenser og linjer med piler for å vise flyt på modellen.
Du vil mest sannsynlig finne grenser for forskjellige betingelser som: Avdelingsinndelinger i et selskap/organisasjon, eller når et konsept er viktig, men ikke egentlig en del av kjerneområdet, eller når mange forskjellige domeneeksperter har motstridende betydninger for det samme begrepet.
Bekreftelse i en betalingskontekst kan bety noe helt annet enn bekreftelse i en fraktkontekst. Det er derfor Bounded Context skal grupperes relatert til språk, betydning og kulturforskjell. Ved å definere bounded context begynner vi å forstå subdomener i domenet vårt og hvordan de samhandler uten å snakke om kode i det hele tatt.
Vi kan følge et enkelt mønster for å kunne dele opp domenet vårt i et veldig sammenhengende område:
- Kommando A (Søk-kommando) utløses og forårsaker hendelse A (Søkt destinasjon).
- Hendelse A (Søkt destinasjon) påvirker visning A (Flyselskap destinasjon søk-visning).
- Visning A (flyselskap destinasjon søk-visning) er også nødvendig når du utfører en betingelse som bruker kommando B (Velg-kommando).
Kommando A (Søk-kommando) og kommando B (Velg-kommando) kan være bra å ha i en felles modul. Jeg har kalt det for "Velge operasjon", som vist nedenfor, og har brukt de samme prinsippene på resten av tavlen/veggen.
Å sette dem sammen kan se slik ut:
Context Mapping
Etter å ha separert og delt opp modulene våre, vil vi kartlegge hvordan de kommuniserer med andre moduler ved å bruke Context Mapping.
En modul sender en forespørsel til en annen modul:
- Velge operasjon-modulen sender en forespørsel med en valgt billett til Kjøpe operasjon-modulen.
- Kjøpe-modulen vår sender en hendelse til en ekstern kontekst (Bank Domene) for å utstede flyselskap-billettkjøpet til banken. En bekreftelses-e-post sendes til kunden rett etterpå.
Derfra begynner du å jobbe mer med de tekniske avgjørelsene og hvordan du skal implementere dette videre i kode ved å bruke Implementing DDD som kilde for Taktisk DDD.
Jeg håper dette vil gi deg mer interesse for taktisk DDD og spesielt Event storming som verktøy!
