Skip to content

Latest commit

 

History

History
63 lines (48 loc) · 3.69 KB

README.md

File metadata and controls

63 lines (48 loc) · 3.69 KB

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:

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)