How far to go when decoupling Microservices by use of Integration Events (Messages)?

Question

I am reading the architecture guide from the .net core project. They state:

The integration events can be defined at the application level of each microservice, so they are decoupled from other microservices, in a way comparable to how ViewModels are defined in the server and client. What is not recommended is sharing a common integration events library across multiple microservices; doing that would be coupling those microservices with a single event definition data library. You do not want to do that for the same reasons that you do not want to share a common domain model across multiple microservices: microservices must be completely autonomous.

There are only a few kinds of libraries you should share across microservices. One is libraries that are final application blocks, like the Event Bus client API, as in eShopOnContainers. Another is libraries that constitute tools that could also be shared as NuGet components, like JSON serializers.

There is a reference implementation, the eShopOnContainers repo on Github. Digging around a little bit, I found that they duplicated the messages in both services. Example: the OrderPaymentSucceededIntegrationEvent appears in the publishing payment service as well as in the subscribing order service.

My feelings vary on this approach. Sure, it is decoupled in the sense of no compile time dependency. But any change of the message might break the application at runtime, since the compiler does not check the compatibility of the message sent matching the message received. Would it be illegal to publish a kind of "Contracts" assembly providing all the messages published by a micro service to be compile time bound by the subscriber? I'd rather think about such messages as "common knowledge", somehow like he base class library is common knowledge for all .net core programs.

Answer 1

One of the greatest promise of microservices is that you will have independently deployable services.

There is a lot forces which fights against this so you should make wise decisions when you introduce anything which is shared amongst different services (a static xml file, a library, a database, etc..)

Whenever you have shared library (for example that one, which contains the contract's objects) you should consider that whenever you make a change how does it affect the services (the provider and its consumers).

• Do I have to deploy only the provider because my change is backward compatible?
• Do I have to deploy all of my consumers first and finally the provider because my change is not backward compatible?
• Is it acceptable that different consumer services may use different versions of the package?

---

The proposed solution (to have duplicate contract objects) emphasises the independency of the services. More precisely it tries to loosen the coupling between them.

A common and great practise is to use Consumer-Driven Contract Testing. The big idea behind this is that each consumer of the provider gives a separate contract to the provider. ("Hey look, this how I use you. You can change in any direction until you can guarantee me this contract").

So instead of testing the provider's API we are testing that from the consumption point of views. With that in mind it makes more sense to separate the contract objects and let the service and its consumers evolve slightly more independently.

There is a really great package, called Pact.Net which can help you write these kind of tests.

Answer 2

I do not have a good answer, at least not a very satisfactory one. However, at its root, the recommendation from .NET site conflates physical boundaries (micro-services) with logical boundaries (business capabilities). This is a non starter. Logical boundary can consist of many independently deployable physical units. In such case, micro-services can communicate using domain events which are valid inside your bounded context.

There is no real way to eliminate coupling in the case of integration events, since contexts must be coupled by something, for example, a contract. In DDD there is no way to eliminate coupling but only ways to minimise it.

It is a fallacy that a micro-service can ever be autonomous. If you slice a monolith into five micro-services then those services immediately acquire the need to communicate, and are bound to each other in some way. Coupling still very much exists, but we are interested in what are the services coupled to. If they are coupled by a common interface (such as integration event) it might loosen the coupling, but never eliminate it.

Another piece of advice is given about sharing only infrastructure libraries (i.e. EventBus). This ignores a very broad and lively concept of Shared Kernels in DDD. Advice like this is a "hardcore" micro-service approach, which might conflict with the guidelines of DDD more often than it doesn't [1][2].

As for integration events, you really have two options here:

• Shared integration events. This can work especially well if your project is a mono-repository which contains your entire bounded context. This means that entire vertical feature slices are delivered at once in a single code integration, which include multiple services. Otherwise, not so much, since you need to update library version in each discrete (micro)service, in each discrete repository.
• Duplicated integration events. If this doesn't entail mono-repository, this becomes a very tedious task, similar to what it is when using shared events library. Here, every time the integration event changes, you need to do multiple service sweeps. You must update a bunch of code in every single one of the micro-services. Atop of that, it clearly doesn't remove any coupling at all. In fact, all services are coupled in the same way. It is now just harder to update.

Footnotes:

1. https://codeopinion.com/microservices-gets-it-wrong-defining-service-boundaries/
2. https://medium.com/@vladikk.com/bounded-contexts-are-not-microservices-ead44b8d6e35