Search code examples
spring-mvcmicroservicescoupling

Microservices and coupling

I am trying to use some kind of microservice architecture. I am trying to use HTTP and JSON as a communication medium (I know better than to call it ReST).

So, I'm using spring-mvc and I wanted to use a class as a ResponseBody on the called and as a RequestBody on the callee. So it so happens that I can duplicate and mirror the class on both the projects, or create a jar and include it in both.

I see coupling in both cases, the first one is duplicate coupling and the other is (I'm sure it has a name) coupling.

And the Request and Response models are not what the projects have in common. I am using event-driven architecture for both and the events are somewhat similar (kinda exactly the same).

What should I do?

Solution

  • Depending on common libraries is not a contradiction to low coupling with microservices. You just want to make sure that the libraries you are sharing are developed for a specific concern that is independent of that of your services and that it doesn't depend on anything within your services.

    Think of that library like you would for a 3rd party library. For example you mentioned that you are using spring - Just the fact that you are using spring in both microservices doesn't mean they are coupled.

    That also means you have to version your libraries and leave it up to the consuming microservices team to decide when they are ready to change/upgrade versions. Here is a link for how to create different library versions in java. Also read this link with some general information about manifests.

    In java you can use one of two approaches for including a versioned library.

    1. Include a version number in the namespace or interface/class name explicitly. This allows for the classloader to have a unique identification and being able to include multiple versions at the same time easily. (Probably the preferred way).
    2. Use the same name and only include a single version of the jar at a time. This means you have to replace the existing jar dependency with the new one and then adopt any potential changes. Check this great answer.

    If your library is a communication client you want to consider supporting multiple versions concurrently at the server side (as to allow the separate microservices teams to adopt to newer versions in their own pace).