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.
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.
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?
Is publishing internal events ( events that other endpoints should never listen to ) and handling them within the same endpoint considered a bad practice?
Should events only be used for integrating with other endpoints?
I think the short answers are: no, no and no 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.