In a Microservice architecture, using client packages to communicate between services, we ran into an issue where two client packages depend on each other, creating a circular dependency.
We are trying to figure out the best solution for this and I’m wondering if anyone would be able to help or point us in the right direction.
Here is the scenario:
- Two services, Car and Insurance
- Two client packages, CarClient and InsuranceClient.
Whenever any service needs to communicate with the Car service, it should use the CarClient package to do so. And whenever any service needs to communicate with the Insurance service, it should use the InsuranceClient package.
The CarClient package has a data transfer object (DTO) Car where one of its properties is insurance. The type for this property is a DTO available in the InsuranceClient package, CarInsurance.
The issue is when the CarInsurance DTO needs to access an enum available in the CarClient package, CarTypeEnum. Now we have the two packages depending on each other.
Possible solutions I can think of:
- This is due to a bad design. Redesign the services and packages to prevent this circular dependency.
- Move the enums into separate packages, therefore, both clients can depend on these packages but the clients wont’t depend on each other.
Any help is appreciated.
Advertisement
Answer
You shouldn’t be sharing any code between services since that defeats the whole purpose of them being 100% independent.
In a MS architecture a CarDTO would only have properties related to a car. If you want information about insurance that would be a separate call to the insurance service to get an InsuranceDTO that has only insurance properties.
When calling either service you would use some key to tie it all together. I.e. you would call the car service with a customerId that you got from the customer service and your CarDTO would have a carId, then you can call the insurance service with customerId/carId to get the InsuranceDTO.