0

Given I have a message bus that can handle commands and events. A command handler can dispatch an event. But should an event handler be able to dispatch another command? Or should event handlers only be able to dispatch further events?

Example:

  1. PostReceivedEventHandler subscribes to PostReceivedEvent, invokes ValidatePostCommand
  2. ValidatePostCommandHandler handles ValidatePostCommand, dispatches PostValidatedSuccessfullyEvent

Is this legit? Or should the logic from the ValidatePostCommandHandler go into the PostReceivedEventHandler and this one should then dispatch the PostValidatedSuccessfullyEvent directly?

Because having just event handlers that have no real business logic in it but just dispatch other commands feels somehow wrong to me.

TiMESPLiNTER
  • 109
  • 3
  • 1
    If the event would not ultimately trigger some sort of command it would indeed be pointless. Just be careful not to do things that might trigger the same event. Ideally event handlers are short, quick and simple. As it gets heavier you may want to queue a message instead and let the other side pull from the queue. This will give you more control and better monitoring. – Martin Maat May 21 '20 at 10:35

1 Answers1

1

Your example looks fine to me, but if you are not comfortable with it, you should look for an alternative design that does feel right.

One alternative could be:

  1. ValidatePostReceivedHandler subscribes to PostReceivedEvent. If a received post is validated successfully, a ValidatedPostReceivedEvent is posted.
  2. PostReceivedEventHandler subscribes to ValidatedPostReceivedEvent.

It is essentially a slight reordering of the handlers so you don't have to send a command from an event-handler.

Bart van Ingen Schenau
  • 71,712
  • 20
  • 110
  • 179