search

cq-rs / cqrs

An event-sourced command-query system for Rust
39 stars 9 forks source link

Subscribe to events for read model population #8

Open i-dentify opened 5 years ago

i-dentify commented 5 years ago

Hi - first or all: coming to rust lately in order to check it out for being a candidate to a new application, I came across this library and I'm happy to have found it - looks nearly exactly like what I was looking for. Kudos!

Anyway - the one thing I am missing so far (at least in the examples), is the story beyond aggregates: read models. In a common event-sourced web application one would not query aggregates but read-optimized read models. However - these have to get created/updated according to emitted events. I have nowhere found any way, how this could be done with this library. I just found the Reactor-thingy, but it appeared to me as if this would be the point to plug in for event persistence but not for any further event subscription. Are there any ways to achieve such a read model population or is it planned in some way? Or did I just misunderstand the Reactor type (being the "way to go")?

davegarred commented 4 years ago

I'm wondering the same thing. Specifically looking for some sort of post-commit hook in the EventSink to a/synchronously distribute the events to downstream views. Is there something I'm missing or is this in the plans?

BTW - very nice work here.

seanpianka commented 4 years ago

@davegarred What is the goal in distributing events to downstream views? How would this be done?

davegarred commented 4 years ago

@seanpianka in a CQRS system all of the "read" responsibilities are taken on by downstream views (or "queries"). E.g., if you add or change a user's email address, at some point you'll want to see that new value reflected in a query.

The aggregate's only responsibility is to apply the business rules correctly and emit appropriate events. Generally it is not visible to the user, though that is not the case in this framework.

These view updates are generally done immediately after committing events with flexibility as to whether they are done in a synchronous or async fashion. (sync is much easier to deal with in a UI while async provides a faster system that is eventually consistent)