Is having multiple event handlers for a single event in a single endpoint a bad practice?

1

Hello,

Having multiple event handlers in the same endpoint, from a logical perspective, seems like a great way to easily be able to design a a system. If the business comes to you and says i know were are already sending the customer an email when the orderplaced event happened but now can you also do something else that talks to a web service when that event happens.

SendEmailConfirmationHandler : IHandleMessages<OrderPlacedEvent>
SomeOtherNewThingThatTalksToAWebService : IHandleMessaged<OrderPlacedEvent>

The problem is now, while code is separated into little units of work, all of these little units of work operate on the same transport message and behaves no differently at runtime as if all the logic for both handlers lived inside of one.

  1. Is it considered an anti-pattern or bad practice to have multiple event handlers listening to the same event ( published by another endpoint ) within a single endpoint?
  2. Is publishing internal events ( events that other endpoints should never listen to ) and handling them within the same endpoint considered a bad practice?
  3. Should events only be used for integrating with other endpoints?
2

Hi @behrygood1982

I have the same thoughts and at present I’m considering three options based on this topic:

  • It should be only one message handler for given Event type per Endpoint
Endpoint_1 
    SendEmailConfirmationHandler : IHandleMessages<OrderPlacedEvent>
        Handle(...) { ... }

Endpoint_2
    SomeOtherNewThingThatTalksToAWebServiceHandler : IHandleMessaged<OrderPlacedEvent>
        Handle(...) { ... }
  • In a given Endpoint there should be one message handler for given Event type responsible for initializing independent work
Endpoint_1
    OrderPlacedEventHandler : IHandleMessages<OrderPlacedEvent>
        Handle(...)
        {
            context.Send(SendEmailConfirmation)
            context.Send(SomeOtherNewThingThatTalksToAWebService)
        }

    SendEmailConfirmationHandler : IHandleMessages<SendEmailConfirmation>
        Handle(...) { ... }

    SomeOtherNewThingThatTalksToAWebServiceHandler: IHandleMessaged<SomeOtherNewThingThatTalksToAWebService>
        Handle(...) { ... }
  • In a given Endpoint each indepentend work should have the own message handler for given Event type initializing the work
Endpoint_1
    SendEmailConfirmationHandlers
        OrderPlacedEventHandler :
            IHandleMessages<OrderPlacedEvent>,
            IHandleMessages<SendEmailConfirmation>				
                Handle(OrderPlacedEvent) { context.Send(SendEmailConfirmation) }
                Handle(SendEmailConfirmation) { ... }
		
    SomeOtherNewThingThatTalksToAWebServiceHandlers
        OrderPlacedEventHandler :
            IHandleMessages<OrderPlacedEvent>
            IHandleMessaged<SomeOtherNewThingThatTalksToAWebService>
                Handle(OrderPlacedEvent) { context.Send(SomeOtherNewThingThatTalksToAWebService) }
                Handle(SomeOtherNewThingThatTalksToAWebService) { ... }

Back to your questions

I think the short answers are: no, no and no :slight_smile: The reason - flexibility. We should be able to design logically independent components in any way especially using events no matter which logical Endpoint will be own the component. From the physical (runtime) point of view, sometimes, like in this scenario, we have to do a little bit extra work to minimize physical dependencies.

1 Like