-
Notifications
You must be signed in to change notification settings - Fork 265
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
Comments
The constructor with this problem was marked obsolete a long time ago. Are there any other problems you have? |
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 |
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 |
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. |
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. |
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. |
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. |
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. |
I agree with you. Thanks for your time! |
This issue was found in Greg Young's sample app first,
and he said:
The text was updated successfully, but these errors were encountered: