Change getEventName access modifier in AggregateRoot from private to protected

[spontoreau]

I'm submitting a...

[ ] Regression 
[ ] Bug report
[ ] Feature request
[x] Refactoring (added because it's not a bug nor a feature)
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior

Currently the event name resolution in the AggregateRoot in private. It's a limitation in the system, especially when your events are stored in an external store. For exemple with Event Store your events will be stored in JSON format with a "type" property to resolve them. In this kind of case, when you're loading the history the different objects doesn't match with any classes of your project (they are just plain object without any type). In consequences, the apply method can not call the "on" handler methods inside the AggregateRoot.

Expected behavior

The method getEventName can be protected so we can override it to change the name resolution of the event. It's not really a bug or a feature (it's just a refactoring to add extensibility to the class).

Example for an aggregate that load events from Event Store:

protected getEventName(event): string {
  if(event.type) {
    return event.type;
  } else {
    // Default behavior (not really usefull for this example
    // but can be use for events that aren't handled by a
    // publisher dedicated to EventStore)
    return super.getEventName(event);
  }
}

PR is comming!

Thanks :)

[chrisflatley]

The same is true for getCommandName and getQueryName (in command-bus and query-bus).

It is worth doing those at the same time?

[spontoreau]

The same is true for getCommandName and getQueryName (in command-bus and query-bus).

It is worth doing those at the same time?

I don't know if it's exactly the same. Here AggregateRoot is abstract and you have to put behaviors and hydrate method in your implementation. The problem is that it's not working when you load external events because you can't override the default behavior to resolve event type (default is based on class name, but external events are anonymous).

For Command and Query is seems different because you have to register handlers with the decorator and the QueryBus / CommandBus is provided as is, so you don't necessary need to extends those classes. That's why I say it's not exactly the same problem ;)

Why do you need to do that?

[spontoreau]

@kamilmysliwiec what do you think about this change?

[kamilmysliwiec]

Thank you @spontoreau. Added in 6.1.0 release

[spontoreau]

Awesome, thanks :)