Is your feature request related to a problem? Please describe.
[AggregateHandler] public static async Task<object> Handle(IEvent<IdentityEvents.V1.CreateIdentityRequested> e, Identity identity, IKeycloakClient keycloakClient)
The above code handles an event and is wired as a subscription handler.
I was trying to also allow it to act as an AggregateHandler.
However, for this to work, the event 'CreateIdentityRequested' needs to contain the IdentityId, which muddies the event.
By wrapping the event with an IEvent<> i was expecting the aggregate handler gen to pull the streamId from the event.
Describe the solution you'd like
Although in most cases, having the subscription forward a message to a dedicated aggregate handler is a cleaner solution, 'single responsibilities' and all, i believe adding the ability for an aggregate handler to source the streamID from IEvent<> would open up more avenues and combinations for people to run with.
Describe alternatives you've considered
Adding the aggregate id to the event being handled by the subscription, which does work, but requires some explicit cde if the event is produced by a start stream, and also requires adding the aggregate id to the event, which is a little dirty.
Forward to a dedicated aggreagte handler from the subscription hander.
Is your feature request related to a problem? Please describe.
[AggregateHandler] public static async Task<object> Handle(IEvent<IdentityEvents.V1.CreateIdentityRequested> e, Identity identity, IKeycloakClient keycloakClient)The above code handles an event and is wired as a subscription handler.
I was trying to also allow it to act as an AggregateHandler.
However, for this to work, the event 'CreateIdentityRequested' needs to contain the IdentityId, which muddies the event.
By wrapping the event with an IEvent<> i was expecting the aggregate handler gen to pull the streamId from the event.
Describe the solution you'd like
Although in most cases, having the subscription forward a message to a dedicated aggregate handler is a cleaner solution, 'single responsibilities' and all, i believe adding the ability for an aggregate handler to source the streamID from IEvent<> would open up more avenues and combinations for people to run with.
Describe alternatives you've considered
Adding the aggregate id to the event being handled by the subscription, which does work, but requires some explicit cde if the event is produced by a start stream, and also requires adding the aggregate id to the event, which is a little dirty.
Forward to a dedicated aggreagte handler from the subscription hander.