Event sourcing gem released

Ciao a tutti,

Non ho capito se l’alto messaggio che avevo inviato alla lista
arrivato,
nel dubbio rimando.

S

egnalo a chi fosse interessato all’argomento che dei miei amici hanno
rilasciato (finalmente dopo 2 anni

di pressing

:slight_smile: ) le gemme che hanno utilizzato nei loro progetti interni per
implementare CQRS+ES.

Lars mi aveva fatto “spiare” durante una conf un po’ di codice
direttamente
dal progetto del cliente, ora me le studiero’.

qui [1]

trovate le slide della loro sessione di 2 o 3 anni fa non ricordo piu’
:stuck_out_tongue:

A

[1]
http://gotocon.com/dl/goto-amsterdam-2013/slides/BobForma_and_LarsVonk_EventSourcingInProductionSystems.pdf

---------- Forwarded message ---------
Date: Fri, Apr 3, 2015 at 2:54 PM
Subject: Event sourcing gem released

Hi Antonio,

I would like to let you know we finally released our event sourcing gem:

https://github.com/zilverline/sequent

https://github.com/zilverline/sequent-sinatra

https://github.com/zilverline/sequent-examples

And on Ruby gems:

https://rubygems.org/gems/sequent

https://rubygems.org/gems/sequent-sinatra

Feedback is appreciated.

Best regards

2015-05-07 19:10 GMT+02:00 Antonio C. [email protected]:

Non ho capito se l’alto messaggio che avevo inviato alla lista arrivato,
nel dubbio rimando.

A me non era arrivato niente, hai fatto bene a rimandare!

Segnalo a chi fosse interessato all’argomento che dei miei amici hanno
rilasciato (finalmente dopo 2 anni di pressing :slight_smile: ) le gemme che hanno
utilizzato nei loro progetti interni per implementare CQRS+ES.

L’approccio molto interessante, me lo studier a fondo. Ci sono un po’
di
punti che non mi sono chiari: per esempio, se due handler possono
reagire
allo stesso evento (gli eventi vengono mandati in broadcast a tutti gli
handler
vero?).

Devo ammettere per che i problemi che lamentano nella presentazione
per zero downtime deployment e scaling mi fanno un po’ paura.

Credo che questo stile di programmazione potrebbe essere portato molto
bene su un linguaggio come Elixir (1 actor per handler, pattern match
degli
eventi da parte degli handler).

On Fri, May 8, 2015 at 10:31 AM Stefano P.
[email protected]
wrote:

L’approccio molto interessante, me lo studier a fondo. Ci sono un po’
di punti che non mi sono chiari: per esempio, se due handler possono
reagire allo stesso evento (gli eventi vengono mandati in broadcast a tutti
gli handler vero?).

Esatto, l’event store fa anche da pubsub ad esempio in sequent l’event
store ha questo pezzo di codice:

def commit_events(command, events)
store_events(command, events)
publish_events(events, @event_handlers)end

Potresti anche decidere di delegare completamente ad un event store
esterno
come ad esempio (https://geteventstore.com/)

Devo ammettere per che i problemi che lamentano nella presentazione per
zero downtime deployment e scaling mi fanno un po’ paura.

Per quello che ho studiato io in realta’ non vedo grossi problemi, provo
a
spiegarmi sapendo che e’ un argomento che meriterebbe una mail a parte.
Il prerequisito, ovviamente, e’ avere almeno 2 istanze dell’applicazione
e
l’event store che fa da pubsub disaccoppiato dalle istanze.
Aggiorni la prima istanza, che iniziera’ a lanciare nuovi eventi per cui
la
seconda istanza non si e’ registrata e quindi non si rompera’ ma a cui
rispondera’ solamente la prima gia’ aggiornata. Dopo procedi
all’aggiornamento della seconda.
Prova a vedere i punti 7 e 8 di questo articolo:
http://cqrs.wikidot.com/case:lokad-hub

DDD (figuriamoci poi con ES) e’ sicuramente ‘troppo’ quando stiamo
facendo
un CRUD ma quando iniziamo ad dover affrontare un problema interessante
da
risolvere, unito a tecniche come Event Storming semplifica enormemente
la
vita (ma qui sto parlando con la voce di amici che hanno gia’ messo in
produzione).

Credo che questo stile di programmazione potrebbe essere portato
molto bene su un linguaggio come Elixir (1 actor per handler, pattern match
degli eventi da parte degli handler).

La tua intuizione e’ corretta :), tratto da Implementing DDD:

However, Event Sourcing is inherently functional in nature. Thus, it can
be
successfully implemented with functional languages such as F# and
Clojure.
Doing so could potentially lead to more concise code that performs
optimally.
qui puoi trovare una bozza semplicistica di implementazione con
elixir:
https://github.com/belgian-elixir-study-group/cqrs/blob/master/cqrs.exs

un collega sta facendo un poc con Scala e Akka-persistence ma i concetti
son quelli.

Happy hacking :slight_smile:
A


da studiare con calma…,
ma sarebbe interessante vederlo al rubyday :wink:

Gio

2015-05-08 15:55 GMT+02:00 Antonio C. [email protected]:

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs