EDA: "Cascading" Events or Explicit commands?

Question

Scenario

Lets say I have three major components of a system:

1. UI - Collects input from the user and creates a LoginUserCommand that is sent over a message bus. The user interface then listens to this message bus for MessageReceivedEvent(s).

2. User Service - receives a LoginUserCommand and raises a UserLoggedInEvent. The critical part here is that Message Service needs to be told to begin receiving messages.

3. Message Service - raises MessageReceivedEvent(s) for logged in users.

Options

The design question I have is regarding the interaction between the User Service and the Message Service.

When a user logs in a number of things need to happen - the services need to coordinate so that the UI begins to receive messages.

Should I...

• Have the User Service raise a UserLoggedInEvent and have the Message Service listen to this event and perform the work required for the user to receive messages?

...or...

• Have the User Service raise a UserLoggedInEvent BUT then create a command - StartMessageReceivingCommand and explicitly send this to the Message Service?

Question

What are the Pros/Cons of each approach? (cascading events vs. explicit commands). Are there any other options?

Answer 1

if your services are real services just raise a userloggedinevent and let the "message service" decide what to do next. the user service should have no knowledge about an message service that needs to start receiving messages if a user has logged in. just raise the event and let every subscriber decide on his own what to do next.

Answer 2

This doesn't make much sense to me. UI itself is not a logical service.

Are the MessageReceivedEvent messages published by the Message Service public enough so that any UI can subscribe to that feed? If not, then maybe these messages should not be published at all.

If a user is not allowed to process MessageReceivedEvents unless they're logged in, then it is the resposibility of the User/Security service to ensure this is not happening.

If MessageReceivedEvents indeed need to be published, then why not have user service running in the UI process?

1. UI process subscribes (sends a subscription request to message service) to MessageReceivedEvent
2. UI sends a LoginUserCommand to remtoe endpoint of the user service and locally handles UserLoggedInReply
3. There are two handlers for MessageReceivedEvent in the UI process
   • first handler belongs to user service and calls bus.DoNotContinueDispatchingCurrentMessageToHandlers() if user isn't logged in
   • second handler belongs to some other service that actually does something useful with MessageReceivedEvents

In step 3, when a user is logged in, the first handler is a no-op. If the user isn't logged in, the first handler stops the other MessageReceivedEvent handlers from runnig at all.

There's more about specifying message order here

Hope this helps