Communicating Between Microservices through Events

On my previous post discussing pros and cons of using a message bus for events and commands I talked about how a good event driven architecture should communicate only through events and why a command should be handled by one, and only one, command handler in a single microservice (i.e: a single domain should deal with a command)


Sometimes I have seen projects where certain domain in certain microservice issues commands to different domains in different microservices to instruct them to do something. This is an anti-pattern in Domain Driven Design.

If a specific microservice wants to communicate with another microservice for something to happen, it should use events. It should publish an event, the other microservice would subscribe to it and do whatever it needs to do to produce another event that would also arrive to the first microservice.

If we decide that a microservice needs to instruct another microservice to do something with a command, we will have a dangerous coupling and  violate the single responsibility principle because the first microservice knows too much about the second one's domain. It is not its responsibility to give commands to another domain, it should focus on its own domain and know only about it.

In fact, it should not know anything about any other microservice, just about certain events that may misteriously arrive if it is interested to be aware.

In any case, if your domain logic requires too much communication with the exterior, maybe this is an indication of a bad definition of the boundaries, so you should review your context map and determine whether interdependencies are really needed or whether you have separated things that should not be separated.

Remember that communication can fail or be unavailable for certain periods and design your system accordingly.

Comments