meteor-space / event-sourcing

CQRS and Event Sourcing Infrastructure for Meteor.
MIT License
63 stars 9 forks source link

Fix/only process external commits containing messages that can be handled #90

Closed rhyslbw closed 8 years ago

rhyslbw commented 8 years ago

From the CHANGELOG:

Commits made in other apps will now only be processed if they contain messages with registered handlers in the current app. Prior to every commit would be returned by the observer, and then it was decided to publish/send, or ignore. The one caveat is that in the future if an app subscribes to a legacy message, it will process all from the past, which may or may not be desired. We may look at introducing rules around processing legacy commits if a natural control surfaces.

So the only issue is that last point. I've not put too much effort into thinking about how we can control this, but it was not acceptable to have every commit processed by all apps, particularly with batch importing of large data sets that spawn new aggregates.

Let's discuss, as it's not a trivial issue, and we may need to have a strategy before merging this. WIP label has been applied for this reason

cc @darko-mijic, @qejk

DominikGuzei commented 8 years ago

I think this is fine – in most cases it should be ok to process all historic messages. The application must decide if/how messages are handled, this is not the problem of the infrastructure.

rhyslbw commented 8 years ago

Sure this is a good point. My concerns would be more credible if this is considered a message queue, but it's not -> it's the historical history of the system's state. So in actual fact would almost be expected behaviour, and I think this can come under the 'Making changes to your production system' section of docs, as it's exclusive to that point in time.

Happy for merge