Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Subscribe to events for read model population #8

Open
i-dentify opened this issue Nov 14, 2019 · 3 comments
Open

Subscribe to events for read model population #8

i-dentify opened this issue Nov 14, 2019 · 3 comments

Comments

@i-dentify
Copy link

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
Copy link

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
Copy link

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

@davegarred
Copy link

@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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants