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

Get rid of the publish operation for the read model since it encourages to implement 2PC #41

Closed
Narvalex opened this issue Jul 20, 2017 · 9 comments

Comments

@Narvalex
Copy link

Narvalex commented Jul 20, 2017

This issue was found in Greg Young's sample app first,
and he said:

Submit a patch (its a relatively trivial one) just make the projections
read directly from the event store as opposed to the publish operation

@gautema
Copy link
Owner

gautema commented Jul 20, 2017

The constructor with this problem was marked obsolete a long time ago. Are there any other problems you have?

@Narvalex
Copy link
Author

That's correct. Thank you. I was just poking around the sample, and the InMemoryEventStore does use an IEventPublisher, which is the InProcessBus I think. Maybe to encourage people to take the recommended approach will be to create some sort of CatchUpSubscription class. If you are agree I could try write one of such

@gautema
Copy link
Owner

gautema commented Jul 24, 2017

There is nothing wrong with using the InProcessBus for this. The only difference from publishing both from the repository is that when publishing from the eventstore, it can happen async and after the events have been saved instead of at the same time

@Narvalex
Copy link
Author

It hurts performance (to ensure commit in the event store and in the bus"), and couples the read model with the write one. And it will be a lot harder to build a new read model and add it to production without loosing events when the trasition occurs. A lot of accidental complexity happens when you need to deploy a new read model that needs to process all events from the begining. To summarize: It makes it harder to sell CQRS to the organization, as oposed to market it as "build a new read model for the new reporting requirement in minutes and put it production right away". My english is bad, Im sorry about that. Im just trying to make a point.

@gautema
Copy link
Owner

gautema commented Jul 24, 2017

If you could give an example of a solution please do. I see that you not want to send all events on an async bus, but I fail to see how this couples the read and write model or how you can build a new readmodel without processing the events from the beginning.

@Narvalex
Copy link
Author

Narvalex commented Jul 24, 2017

I think that I did not explain myself well. I will try again: With the current code, if you want to have a new read model you write one and register it into the bus, but you will only receive the new events from now on. There is not a simple way to make it process from the begining, and when catched up make it process live.

@gautema
Copy link
Owner

gautema commented Jul 25, 2017

Ok, I understand, and agree that this is not easy. I can also understand that the InProcessBus might encourage using an ESB and 2pc, but I think the publish operation with automatic registration of handlers is useful even if it has some problems. I thought about renaming the InProcessBus to something else a while ago since I think the naming is what causes most confusion, but decided against it since I didn't think a renaming was worth a breaking change, but I may have been wrong.

@gautema
Copy link
Owner

gautema commented Jul 25, 2017

And by the way, if you have any ideas on how to make things more clear or make it easier to add new read models I'm all ears. But I also don't want the framework to be to hard to start with. I find it better that people grow out of using it after a while than not get started at all.

@Narvalex
Copy link
Author

I agree with you. Thanks for your time!

@gautema gautema closed this as completed Jul 28, 2017
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

2 participants