0

Hopefully this topic is not opinionated and I could maybe get meaningful answer please. Our problem is, imagine you have two microservices: Car and Driver. DTO of the driver could be let's say as following:

DriverDTO 
{ 
  id: 1, 
  name: "John Smith" 
}

and CarDTO:

CarDTO
{ 
  name: "Ford", 
  driver: { 
    id: 1,
    name: "John Smith"
  }
}

This model involves composition of microservices which could be not very nice way how to maintain loose coupling between services - if you update DriverDTO (no breaking change, just adding a field), you have to update all the microservices consuming it if they need it, because frontend is expecting from "driver": just the whole model as provided in Driver service.

If we do it as following:

CarDTO
{ 
  name: "Ford", 
  driverId: 1
}

Then we need to do additional request from frontend. This could be solved by service composer though.

We have to decide between two choices:

1) We are thinking about service composition in API gateway, so basically frontend -> API gateway (Spring Zuul) -> (2 calls, to car AND driver service) and it will create a nice composed result as seen in the second code block above.

2) We have to stick with to the approach - the Car service (and other service as well) are consuming it and they need to add a new field if they REALLY need it. So the field driver: does not have the same format across all microservices.

What do you think?

  • What are your tradeoffs? Every approach to a computing problem has its pros and cons within the context of your specific project. Have you identified and evaluated those pros and cons for both choices? – Robert Harvey Oct 25 '18 at 22:15
  • 1) CONS - single point of contact and sounds a bit monolithic. added effort to maintain another deployment in kubernetes cluster PROS - caching in composer, frontend can use both services (api gateway and also direct to microservices) 2) CONS - Too many model dependecies between microservices in our cases. Lot of services are including other responses in their model - impact on junit tests. too much work PROS - no other extra pod in the network, – Mejmo Oct 25 '18 at 22:28
  • well, I'm liking the API Gateway option. – Robert Harvey Oct 25 '18 at 22:31
  • point 2 doesnt make sense to me, can yoi reword it at all? – Ewan Oct 26 '18 at 6:32
  • We add a new field "lastName" to driver. So ti means that all other services which have driver field (they include DTO object from driver service) have to be updated to have this new field. Because in Java all fields have to be defined to expose them. It means that every service which is including DTO driver, should update this DTO, so that they can expose all fields from the original driver DTO from driver service. – Mejmo Oct 26 '18 at 7:23
1

A common mistake in micro-services is to have low-cohesion, of which this is an example.

If a driver belongs directly to a car, and they are always used together, then they should be part of the same micro-service.

You want to aim for the best ratio of cohesion to coupling which you can get. Separating car and driver seems to be low on coupling, but also low on cohesion.

However, my guess is that this seems to be a contrived example, so perhaps your real problem does need to be in separate services; hard to know without more information.

  • Our problem involves 10 microservices. You can imagine for example ... user object. 5 microservices have user field in db and imagine you have to update all their userDTOs when there was some new field added on user-service. Now let do not consider any saving to JWT token, but you get my point.. – Mejmo Oct 25 '18 at 23:02
  • I think you're mixing cohesion and coupling. Splitting a cohesive service will lead to more coupling between services. Splitting an incohesive service will lead to lower cohesion, if done right. Joining services works in the opposite way. It might lead to less coupling (between services) but it might also lead to less cohesion. – COME FROM Oct 26 '18 at 10:43
  • 1
    @Mejmo what property could you add to a user that 5 microservices will need to know it? As this answer proposes, you very likely need a microservice that deals with cars and drivers (together). But this service probably won't need to know the driver's name (I can't imagine a business rule that mixes driver name and car), but might need to know the driver's driving license (to validate if the driver is allowed to drive a particular car). – Francesc Castells Oct 30 '18 at 20:06

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.