Getting correct aggregate state in subscriber

[dco123]

As stated in #562 we can get the aggregate state from the aggregate store, but i think this will be the latest state and not necessarily the correct state for the sequence number attached to the event being notified. Is there a way to get the correct state for the sequence version of the event? Ideally the correct state of the aggregate would be passed into the subscriber

Thanks

[dco123]

I guess the answer to this will be that the subscriber should maintain its own state. My issue is that my subscriber only exists to publish a public representation of that event somewhere, but that public event message also includes the state of the aggregate after the event occurred.

It feels like overkill to have to maintain the aggregate's state in the event publisher. An alternative is the aggregate event includes a copy of the aggregate state after it is applied, so the subscriber has access to the aggregate state through the aggregate event. But that has a chicken and egg problem, in that the state gets updated after the event has been emitted, so at the point of creating the event I don't yet know the updated state.

A way around that could be to make the event class mutable and add a copy of the aggregate's state into the event after it is applied, with the expectation that this change to the event would make it through to the subscribers, but that's not ideal and I'm not sure if it would work, so I'm hoping there's a better way

Thanks

[wgtmpeters]

I would not prefer to use the actual aggregate to get the information you need. Either the event should contain the data you need or you could build up readmodels for such cases.

And it's also very unlikely the aggregatestore or readmodel contains newer information as what was available when the event was published. It's not impossible offcourse but if you have such frequent parallel updates the the same aggregateId they will very likely be retried because updates happen on old aggregate versions.

And as you stated the only way to prevent this is to contain the information you need in the event it self.

[dco123]

Yes, agreed. I'll close this as I don't need it anymore. Thanks