The event handler must be a pure function that does not have any side effects but only use the state and the event passed to it to create a new state.
Best is probably to either do that just like you have started implementing, in a command handler of the ESB itself turning it into another command that contains all that is needed, or alternatively in another actor or composed future in front of the ESB (Event Sourced Behavior) actor, combining the command and the needed additional data into a single command that the event sourced behavior can process, store as one event, and apply atomically to the state.
This will highlight at least two things to consider:
- Other commands could come in between receiving the original command and it completing loading data, should those be handled, or delayed until fetching is done?
- The risk of the ESB stopping/crashing in between receiving the triggering command and asynchronously fetching additional data completing, for example if you run it in sharding and it is rebalanced between nodes – if you need a guarantee that happens without a client retrying the original command you will need to store an event with the intent to load that data (all the details of the original command) and re-trigger on recovery.