1

I'm working on a microservice project, and I have a question about best practices.

We are using Java Spring, and all of our models are packaged in a single JAR. Each microservice depends on this JAR to function. Is it okay for a microservice to depend on a JAR containing models outside of its scope like this, or is it better practice to split this JAR up?

dianis801
  • 61
  • 6
  • 2
    Shared dependencies (or shared *anything*) and microservices don't usually mix very well. – Kayaman Mar 19 '20 at 20:47
  • 6
    Does changing the jar require changes to **multiple** microservices? If yes, then it's not really a microservice since it cannot be managed independently. – Andrew S Mar 19 '20 at 20:53
  • Duplicate of questions such as https://stackoverflow.com/questions/48961000/why-shared-libraries-between-microservices-are-bad – tkruse Mar 20 '20 at 13:30
  • Plenty of such questions really, like https://stackoverflow.com/questions/47860278/best-practice-to-share-domain-model-between-two-microservices – tkruse Mar 20 '20 at 13:35

2 Answers2

2

A very good article by Bartosz Jedrzejewski here

To quote a relevant part from his artcile...

If the service code should be completely separate, but we need to consume possibly complicated responses in the clients- clients should write their own libraries for consuming the service.

By using client-libraries for consuming the service the following benefits are achieved: Service is fully decoupled from the clients and no services depend on one another- the library is separate and client specific. It can be even technology specific if we have mix of technologies Releasing new version of the service is not coupled with clients- they may not even need to know if the backward compatibility is still there, it is the clients who maintain the library

The clients are now DRY - no needless code is copy pasted It is quicker to integrate with the service - this is achieved without losing any of the microservices benefits This solution is not something entirely new- it was successfully implemented in Scott Logic projects, is recommended in the “Building Microservices” by Sam Newman (highly recommended) and similar ideas can be seen in many successful microservices architectures.

There are some pitfalls as well, better read the entire article...

flaviuratiu
  • 158
  • 8
1

Sharing the domain models is an indicator of bad design. If services share a domain, they should not be split. For Microservices, teams working on one service should be able to modify their domain objects anytime without impacting other services/teams.

There can be done exceptions though, e.g. if the model objects are non-specific enough to be reusable in any service. As an example a domain of geometry could be contained in a geometry library. There can be other exceptions.

tkruse
  • 10,222
  • 7
  • 53
  • 80