partsregister-eventsourcing

Test av en enkel eventsource versjon av et Partsregister.

Bruker en lesemodell (Read model/Query model) som nå ligger i samme JVM og lytter på nye eventer over en EventBus. Kjører med Jetty og kan lett brukes i en container som Docker.

Oppbygging

• Et tydelig skille mellom lese og skrivemodell.
• Skrivemodellen skal være en eventstore.
• Eventer skal publiseres slik at nye lesemodeller kan lages efter behov. (Guava sin EventBus i eksemplet)
• Publisering kan gjøres med en køløsning, Vert.x, feeds eller en distribuert NoSQL som Hadoop, MongoDB, CouchDB evt. EventStore.
• Lesemodellen kan i starten finnes sammen med skrivemodellen og flyttes til annen JVM/container etter behov.
• Snapshot kan legges på efter behov for bedre ytelse.

API

Hver ressurs har underressurser med kommandoer og eventer. God strategi? -> Kommandoer passer ikke så bra sammen med ressurs og CRUD. Eller kommandoer som "rot" ressurser? /navneendring /flytteendring etc.

Bruk

Embedded server

Kjør TestServer -> localhost:8180/rest/

Jetty med mvn

Start Jetty med mvn jetty:run -> localhost:8080/rest/

URLer

baseurl/parter
baseurl/parter/{id}/events
baseurl/parter/{id}/endre_navn
baseurl/navneendring
baseurl/partview/{id}

Videre mulgheter

• Jobbe mer med REST APIet. Få til Jersys linker bl.a. For å følge HATEOAS.
• Skille ut lesemodellen som lytter på eventer (i egen pakke nå: ske.part.partview)
• Tilby et API for å hente eventer (som feeds? hente fra en gitt aggregate root og en sekvens id? hente alle med paging?)
• Legge til en ny lesemodell som aggregerer informasjon som f.eks. statistikk - enkel event monitorering . Lytte på eventbussen og aggregere informasjon. REST API til dette. (/rest/partmart?)
• Bruke Vert.x sin EventBus isteden for Guava slik at handlere kan startes i flere JVMer. (Hvordan håndtere at Vert.x sin eventbus går ned? Hvordan håndtere at handlere går ned?) API som henter eventer fra en gitt id eller tidspunkt, )
• Lage Text Fixtures for enklere å teste Command - EventSource - state til aggregatet.
  • Given - denne event historikken
  • When - denne/disse kommandoer utføres
  • Then - skal tilstanden til aggregatet bli slik (og disse eventer skal bli generert med disse verdier)

Kanskje det mest spennende for tiden:

• Bruke Hadoop som persistering for eventstore (eller annen kilde som kan leses av Spark) og Spark for analyse/Event monitorering/Complex event processing.
• Og evt. Akka persistence som Aggregater med en Journal plugin

Og videre...

• ...en mer rik funksjonalitet i domenet
• Versjonering av eventer (med oversettere slik at handler metodene kun trenger å håndtere siste versjonen)
• Snapshotting av aggregate state (med Memento pattern)