[Question] Shared integration events

[AlexanderSysoev]

In your application integration events has duplicate in several microservices. For example UserCheckoutAcceptedIntegrationEvent is located in Basket.API and Ordering.API. Would it be the best to share contracts between microservices (place integration events in separate assembly)?

[ardalis]

The goal for microservices is that they be self-contained, and not have to be updated based on changes in other projects or services. Thus, some duplication is desirable in this case if it means that changes in one microservice do not need to impact the others.

[CESARDELATORRE]

@ AlexanderSysoev - Great question! 👍
@ardalis - Agree. Unless it is about NuGet packages with re-usable libraries "agnostic" of the project, such as cross-cutting-concerns like a library for handling JSON, or a library for handling Http resilient communication (Polly, etc.), data structures, DTOs, etc. data structures, code or DTOs should not be shared across microservices as they could be developed by completely independent development teams.

THE POINT: Share between microservices only what you would also share between different/independent applications. 👍

However, In the specific case of Integration Events I should also say that some developers prefer to share the types/libraries between microservices. In this case we chose to be more independent between microservices, so not to couple multiple microservices to a single "event's library".

[mvelosop]

Hi @ardalis, @CESARDELATORRE

I know we've talked about this more than once, but I'm hanging on @CESARDELATORRE's last paragraph.

I think that there IS A REAL AND IMPORTANT dependency between microservices that share integration events, because those teams at some point reached an agreement to settle on that information exchange spec (it's a contract after all), so I think it's actually good to have that dependency expressed in code somehow, and a shared library looks like a good option.

Am I way off?

[CESARDELATORRE]

My point is that for microservices integration you should take a similar approach than for application integration. Both microservices and application development must be independent/autonomous.
It could be that initially those teams are collaborating, but it could also be the case where multiple teams don't have such a close collaboration in the same way that you could publish HTTP services for external application integration and you don't provide a library/assembly with the DTOs or Events because that would cause a strong dependency between the services and the external applications.
I think it should be the same case for microservices. They must not share "business" assemblies, only cross-cutting concerns NuGet packages of libraries that you'd treat like external NuGet packages.

But, as always, this decision must depend on the application's context.

[mvelosop]

Fair enough!

[Carl-Hugo]

In the case each microservice has its own copy of an integration event:

1. If one microservice change an event, get deployed, then publish it.
2. All other microservices subscribed to (relying on) that event will (or could) break.

So, as mentioned by @mvelosop there was, at some point, an agreement that created a contract.

That leads me to the following conclusion (feel free to add to it, by agreeing or disagreeing):

• Sharing the contracts using an assembly creates a dependency on that assembly.
  • This could be shared and versioned using a NuGet package (at an extent it could also be used to manage multiple version of the same events).
  • That same assembly becomes the source of truth for events stored in it.
  • This assembly becomes a catalog of events, making the event discovery easier.
  • Contracts could even be enforced at compile time (in a CI/CD pipeline for example).
• While copying all classes:
  • Hides those dependencies
  • Makes the discovery of those dependencies harder
  • Does not add anything (I can think of some edge cases where it could add a little)

So whatever the technique used, the messages (events) still need to be in the same format (or at least be similar) in all microservices (publishers and subscribers), so the dependency is there no matter what (hidden or not).

Personally, for most scenarios, I think I'd go for discoverability and code sharing (DRY) over "falsy decoupling" and copy/paste.

Finally, as stated by @CESARDELATORRE : "But, as always, this decision must depend on the application's context."

[mehdipayervand]

@AlexanderSysoev Consider each microservice would be developed by different language and different platform for example python or java.
as it is RabbitMQ and REST both have their own implementation so one team have Python skill and experience and so on.

[mvelosop]

Closing this discussion now (it was a nice - and recurring - one), will reopen if needed.