Demonstrerer en event-sourced arkitektur implementert i Akka
Java
Switch branches/tags
Nothing to show
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
src
.gitignore
README.md
pom.xml

README.md

Eksempel på implementering av CQRS med Event Sourcing i Akka. Noen todos er plassert i koden som en liten start-oppgave...


Til alle dere andre som også har sett sannheten og lyset:


Noen tips og regler vi har kommet frem til etter en hel masse roting (NB: Sikkert noen som er uenig i en eller flere av disse, dette er vår take hittil)

  • Eventer skal være en minimalistisk beskrivelse av en hendelse som endrer tilstanden i din applikasjon, og ikke inneholde implementasjon-spesifikk informasjon.
  • Event-navnet skal beskrive intensjonen bak endringen i tilstand. Motstå fristelsen til å lage generelle hendelser, f.eks. av typen " BrukerInfoEndret" med verdi som beskriver hvilket felt det gjelder.
  • Prøv å unngå CRUD-style events/commands; meldFlytting -> flyttingMeldt er bedre enn oppdaterAddresse -> adresseOppdatert.
  • En projeksjon skal bare lytte til eventer i ett aggregat.
  • Commands skal inneholde så lite informasjon som mulig. Det er command handlerens oppgave å f.eks. slå opp i projeksjoner for å skaffe det nødvendige for utførelse, ikke controlleren.
  • Sagaer og projeksjoner skal bare motta eventer fra event-store, aldri direkte.
  • Event-store skal bare leses sekvensielt for å publisere til projeksjoner eller sager, ingen ad-hock spørringer er lov.
  • Unngå gjenbruk, ikke eksponer eventer direkte gjennom projeksjoner. Lag heller nye objekter tilpasset det spesifikke formålet.
  • Verken command handlere eller projeksjoner skal noen gang dispatche commands. Dette er reservert for kontrollere og sagas.
  • En projeksjon eller saga skal ikke gjøre queries mot andre projeksjoner.
  • Foretrekk flere enkle sagaer over en kompleks.
  • Foretrekk flere formåltilpassede projeksjoner over en generell.