How to share entity between REST service between two microservices?

Question

I have created two micro-services using java. I need to make a REST api call from service A to service B. The data sent will be in JSON format. Using jax-rs I need to create entity class in both the service.

Since both the entity class be same in both the projects. Do i

• Create an common jar and use is for all my entity/domain objects? Does this make my microservice more tightly coupled?
• Do i create the same class in both the microservice projects? This will just mean repeating the work in both the projects?

Is there a better way to communicate between the sevices?

Answer 1

In terms of having your two micro services independent and having them also independent in the future I would also duplicate the code. We had the exact same situation before. Several microservices seem to use some "common" classes that can be put to a seperate jar. In the end we had following situation:

• several (5+) services using the same JAR
• turned out that classes that we thought are the same, seemed to have slightly different semantics in different services
• a change on one of the classes more or less forced us to have a release on every microservice, when it came to releasing (no independency here anymore)
• developers tend to see "common" behavior everywhere, so you most likely end up with some "Helper/Utility" classes there as well which is in the meanwhile considered a code smell in OOP

Long story short, in the meanwhile we switched to having the code duplicated, which gives us the freedom to handle our mircoservices really independently, as we only need to stick to the service contract. What happens internally is fully up to the service and we don't have to release all services in the end of an iteration. I'm not saying that the other option is wrong, but it turned out that it was not suitable for us. If you really see common classes between two services and you are sure you don't mess your common library up with other crap, your save to go.

EDIT

Maybe as follow up, we had the same discussion in regards of tests (unit and integration) having share test code in some common classes. In the end this was hell, as every slight change in code or acceptance criteria made 50% of tests fail. Meanwhile our strategy is to not share anything on test level and have everything right at the tests place. By that you are super fast in eliminating or changing tests. In the end the lesson for us was to keep business code as clean and elegante as suitable and the test code in a way to give us the least headache possible.

Edit2 Meanwhile, we define all our REST interface with open api specifications and create the actual DTO objects that are exchanged via the maven plugin openapi-generator. The spec resides in the project that implements the interface and it is published to artifactory. The project implementing the client pulls it and creates DTOs based on that. By that, you have a single point of truth and no need to write DTO boilerplate code.

Answer 2

I'd say it depends on the situation. If you use a shared package, this will introduce a coupling between the two projects. This makes sense, if both of the project build up on the same data classes and therefore will have the same dto objects to work with. Ideally you would have your own nexus which simplifies the usage of the shared artefact. Otherwise, if only a few classes are redundant I probably would implement it in each sevice separately, which decouples them too.

I am afraid that you need to decide which one the right solution is for your project.