The classic EDA example involves a command triggering events - like a chain of dominos.

PlaceOrder -> OrderPlaced -> PaymentSucceeded -> OrderShipped

Typically the Order Service listens to events along the way to keep the status of the order updated. Presumably (and this is the part that every article skips!) because at some point the order service will receive a ViewOrder command, which will require a response beyond "OK".

So my question is: In a EDA, do at least some of your services have to react to both events and commands?

If not, what architecture could separate the "command world" (required for supporting a HTTP API) from the "event world" of services performing async processing?

CodePudding user response：

In my experience, every microservice we've built does both things. Participating with the Messaging Plane (publishing and/or subscribing) is always a requirement, and in most cases, exposing at least one API endpoint is also a requirement. In fact I don't believe we have any live services that don't expose an API endpoint although we have a few that probably could be that way.

So far, we've not run into a case where there was value in splitting a service into separate parts for API serving vs event bus interaction. I wouldn't say that's impossible, but we are very focused on services encapsulating a (functional) domain without much concern for implementation. That has allowed us to use a very formulaic approach to creating services themselves which is a big part of why we chose this architecture style.