Fix: Supply another mechanism for event naming

[rasmus]

As mentioned in #903, events with the same name created in different namespaces will collide. While there is a workaround using [EventVersion], the OOB experience should be that it should merely work.

An idea would be to create some settings that developers are forced to do during EventFlow initialization, like selecting the naming for events. Then introduce a new naming convention named NamespaceAndClassName along side the existing ClassName naming.

[github-actions]

Hello there!

We hope you are doing well. We noticed that this issue has not seen any activity in the past 90 days.
We consider this issue to be stale and will be closing it within the next seven days.

If you still require assistance with this issue, please feel free to reopen it or create a new issue.

Thank you for your understanding and cooperation.

Best regards,
EventFlow

[github-actions]

Hello there!

We hope you are doing well. We noticed that this issue has not seen any activity in the past 90 days.
We consider this issue to be stale and will be closing it within the next seven days.

If you still require assistance with this issue, please feel free to reopen it or create a new issue.

Thank you for your understanding and cooperation.

Best regards,
EventFlow

[SeWaS]

Hello there 👋

I was thinking a bit about that problem recently. Let's see if I got that right: Wouldn't the EventDefinitionService be a potential place to apply such a naming strategy?

More precisely, as the method CreateDefinition(int version, Type type, string name) gets a version, type and name (either the event's classname or the value coming from the EventVersionAttribute) already injected, we could use those parameters, forward them to a strategy and get a strategy-applied eventname. Depending on the strategy, we might want to construct a name based on those values.

A default strategy could then be something like a VoidStrategy which simply returns the given name. That is the current behavior and thus would not introduce a breaking change.
A NamespaceAndClassName strategy could be provided as a built-in strategy which had to explicitly be picked when configuring EventFlow.
It would also be possible to allow devs to implement their own strategy and apply it.

Bottom line, the EventDefinitionService could look something like this:

protected override EventDefinition CreateDefinition(int version, Type type, string name)
{
    var strategyAppliedName = _eventFlowConfiguration.EventNamingStrategy
        .CreateEventName(version, type, name);
            
    return new EventDefinition(version, type, strategyAppliedName);
}

Hope that makes sense 😅 Any opinions or objections?

[SeWaS]

Any opinion here? Otherwise I would go ahead and open an PR based on SeWaS@28fad0b.

[rasmus]

@SeWaS that would be awesome!

I had a look through your commit and maybe simply rely on the IEventNamingStrategy being in the IoC instead of a member on the configuration as that aligns more with the rest of the code base.