These are chat archives for RBMHTechnology/eventuate

11th
Jul 2016
Alexander Semenov
@Tvaroh
Jul 11 2016 04:23

Hi, @krasserm. I'm revisiting something I was trying to do with Eventuate half a year ago and it seems to me that the full-blown event sourcing architecture is not suitable for my task.

The problem is that my write model (the one I should validate commands against) is a graph. It's complex and I can't represent it as case classes in actor's internal state. I need to perform graph traversal, index searches, etc to validate commands. And even if I could represent (in-memory Neo4j) it I would end up with whole user data in memory.

Alternative simplified (or not so) architecture I'm thinking of is getting rid of commands validation at all. Every command would just produce some events and let the external read model (graph database) writing process be responsible for validation. For example, if I'm processing the CreateTreeNode(parentId: Id, ...) command, I would produce TreeNodeCreatedEvent(parentId: Id, ...) and return a specific error code from the DB facing API if parentId does not exist. On event replay of course I would re-try such failed commands but that's not a problem. I would like to handle only application-specific errors, like NotFound, Conflict, etc and let infrastructure errors (like db not available) to re-try failed events.

But I need also to react on application-level events processing failures, if I've got NotFound error code I need to notify the initial command sender about it. Here is the problem: I can't create new commands from events handlers, right? But what if I could? Of course I would need to not create 'em on events replay, not sure how to ensure that.

Could you leave some your thoughts/suggestions about the problem I have here? I would like to re-use some great Eventuate features like replication, events persisting and still be able to adapt it to an architecture I could be comfortable with. Thanks!

Alexander Semenov
@Tvaroh
Jul 11 2016 05:08
Probably in event handler I can create new commands but then I would need to distinguish between events replay and ordinary events processing. Not sure how bad it is.
Volker Stampa
@volkerstampa
Jul 11 2016 13:09
@Tvaroh Sounds like you are trying to do command-sourcing and not event-sourcing and eventuate might not be the ideal framework for this. Maybe it makes sense for you to use your graph-database in a non-eventsourcing manner and just emit events where needed e.g. for event-collaboration
Creating (and sending) commands in an event-handler is very well supported by eventuate, though. You would typically use ConfirmedDelivery for this as with this you can ensure that your command does not get lost and is not re-delivered on replay if successful delivery is confirmed. But depending on your requirements you could also explicitly check with recovering
Alexander Semenov
@Tvaroh
Jul 11 2016 13:48
@volkerstampa thanks! Since I'm only interested in sending commands (from event handlers) to actors working on the same JVM, I probably don't need ConfirmedDelivary, right? Would be also cool not to replicate failed events but that's too late at that point.
Martin Grotzke
@magro
Jul 11 2016 15:23
@Tvaroh Commands are not necessarily processed, e.g. the system could be shut down before a command is processed. You'd need to use ask to get the acknowledgement.
Alexander Semenov
@Tvaroh
Jul 11 2016 15:28
I see