Is your feature request related to a problem? Please describe.
I'm working with the @ocoda/event-sourcing module in a scenario where event types are dynamically defined in the database. Our system supports user-defined actions that trigger domain events, so we can't predefine all event types statically at compile-time.
However, the current framework design requires event names to be declared statically via the @event('EventName') decorator, as documented here.
This poses two main challenges:
- All events of a given class are treated as the same type, even if their actual semantics differ — we use a dynamic type field in the event payload to differentiate them, which feels like an anti-pattern.
- It's not possible to register new event types dynamically at runtime, because the event name must be bound to a class at compile-time using the decorator.
Describe the solution you'd like
We’d like to request or discuss support for dynamic event typing, ideally allowing:
- Custom event type resolution from metadata (e.g. a type field in the payload).
- A more flexible registration system for deserializing events based on runtime data.
- (Optional) A fallback or generic event handler that can process unknown or loosely-typed events.
This use case is common in systems where the domain logic is extensible via configurations or user-defined flows.
Would this be something that could be supported or discussed as a future improvement?
Thanks for the great work on the library! 👏🏻
Is your feature request related to a problem? Please describe.
I'm working with the @ocoda/event-sourcing module in a scenario where event types are dynamically defined in the database. Our system supports user-defined actions that trigger domain events, so we can't predefine all event types statically at compile-time.
However, the current framework design requires event names to be declared statically via the @event('EventName') decorator, as documented here.
This poses two main challenges:
Describe the solution you'd like
We’d like to request or discuss support for dynamic event typing, ideally allowing:
This use case is common in systems where the domain logic is extensible via configurations or user-defined flows.
Would this be something that could be supported or discussed as a future improvement?
Thanks for the great work on the library! 👏🏻