A pattern language and visual notation for messaging systems: Enterprise integration patterns by @ghohpe and @bobby_woolf
One of the defining characteristics of the microservice architecture is that services are loosely coupled. Services should ideally be self-contained but some form of inter-service communication is inevitable. You should, however, be very careful about using synchronous calls (e.g. REST or gRPC) between services If you mimic the inter-module communication patterns in your monolithic you are likely to have a very brittle system due to the runtime coupling. To reduce runtime coupling, you should strive to use asynchronous messaging wherever possible.
It’s a pattern language and visual notation for messaging systems.
I find it useful to describe an application’s architecture in terms of patterns such as Message Channel rather than immediately leaping into the technical details of today’s fashionable message broker. Later you can map that abstract architecture to an actual implementation. For example, take a look at the diagrams in my posts about orchestration-based and choreography-based sagas, such as the follow:
This is a must read book if you are building applications that use asynchronous messaging. You can learn more about the book and the pattern language on the book’s website.