Sharing DTO objects between microservices

Question

TL;DR - Is it ok to share a POJO library between services?

Generally we like to keep the sharing between services strictly limited to none if possible. There has been some debate whether or not the service that is sharing data should provide a client-library for clients to use. The client-lib is generally optional for a client of the service to use and can consume the API however they please, whether to use the client-lib, or use an alternative language and use the general aspects of the library and such.

In my case - I am consider a service that create an object of data. Let's assume this object is a PET. It is NOT the database entity, but strictly a POJO that implicitly represents the underlying data. This POJO is what the API has defined. Assume: Pet - Age, Weight, Name, Owner, Address, Species, etc.

Service 1 - PetKeeper: It will generate a pet for whatever reason and retain all of the data and must reference this service to obtain the pet, or make modifications to the Pet, lets say the name changes, or address change must be done through an API call to this service.

Service 2 - PetAccessor: This services gathers the pet's and does validation checks

Service 3,4 - More intermediate service calls

Service 5 - User Inteface

These are very arbitrary but the point is simple. The UI or some user-facing service wishes to present in some way this "PET" object. It must call through an API a service, which calls a service, which calls a service, etc until it reaches the service which gathers the required information and begins the relay back. Finally the UI service has the PET object to display.

This is pretty common - but with our absolute mentality, we duplicated the PET object in every service. DRY (don't repeat yourself) principle only applies to code INSIDE a service and doesn't apply across services but the point is still there. What if we add a field... we must modify 5 services of the POJO in each.

--OR-- We can provide a Pet-Objects-Library which contains some of the pojo's from the API and each service can import/dependency on the library. There is no dependency on the service(s) themselves, but just the general library. I like this idea so that each service has the same type of object and updates are easier. But I'm concerned about God-Objects.

What are the pro's/con's - what's the best design? What have you done to pass data between services to minimize repeating the same POJO classes while also staying de-coupled?

Answer 1

What's the best design?

You can reuse the same Pet DTO object among the backend services (which process the typical business logic), but when it comes to the presentation tier (User Interface), it is generally a good practice to use a FormBean (a different bean with added fields for presentation logic) so that there will be a clear separation between presentation logic and business logic.

This is required because services should be reusable and a single service can be exposed/reused by multiple/different endpoints (like frontend or could be a different webservice, etc.. ) and each of those endpoints might require additional fields which will be populated by the respective Controllers or layers (like adapters) above the services.

What have you done to pass data between services to minimize repeating the same POJO classes while also staying de-coupled ?

If you use a single bean between business and web tiers then you are tightly coupling the presentation logic with business logic which is not good practice and you will end up changing the services for a requirement in the Frontend (like for example, a different date format to be shown in User Interface). Also, to make this process of populating/copying the data across the beans (like DTO to FormBean or Viceversa), you can use libraries like Apache BeanUtils.copyProperties() or Dozer to avoid the boilerplate code.

Answer 2

If the DTO represents the same business entity in all the microservices there should be only one class, shared among the services. It's (almost) never correct to have duplicate code for the same object.

Answer 3

The way how I plan to do it now, is that each service packages only DTOs and put them into Nexus as jar lib. When other service need those, it will get thos DTO lib(s) as dependency in manve/gradle. If new DTO version is released on one service, its fine as long as old version is also supported at the same time, so don't break backwards compatibility, versioning, etc.. so this is backend-to-backend area. Also to prevent circural dependency you are better to separate service from dto packaging

Now look at backend-to-frontend and vice versa I disagree with previous comments that UI as presentation layer is different. IT IS NOT!!! UI is just another microservice to me which also consumes and produces events.

Backend-to-frontend direction What I do is to convert POJO(dtos) to Typescript interfaces and package into NPM and load them into Nexus as well. UI nodejs based project then consumes and uses those. This is way service to UI.

Frontend-to-backend direction For UI to service layer events I convert Typescript interfaces and convert them to POJOs(dtos), package as jar and upload to Nexus (or some repo) in form of jar to be consumed by backend services.

These processes are easily handled by CI processes (Travis, Gitlab CI, etc.)

Any comments to this approach welcomed.

Answer 4

Neither. Your services aren't microservices.

You have unfortunately created a "distributed monolith" or "hidden monolith".

1. Your services aren't loosely coupled. A change in one service will probably result in a change in another service. Often this will require simultaneous deployment of multiple services.
2. Your services aren't loosely coupled. You require synchronous communication between services. If one service is down then all the services above it are down (and as a bonus the services below it might as well be down).
3. Your services aren't loosely coupled. They won't scale independently, if you have a spike in traffic in one service you will see that reflected in every service because they all call each other.

You should (sorry) go back to square one. Reconsider if you even need microservices or if your goals can still be served by a monolith. If you decide that you do need microservices then have another go at extracting them looking for business capabilities, bounded contexts, data-rich services, etc.

Once you've done that then you shouldn't have much/any need to share these objects around anyway, so your problem will be solved.

Answer 5

The challenges with shared code between services is merely the good old question about dependencies.

There is no right or wrong here, but a balance and tradeoffs for the path you choose. And this path I would argue is quiet significant in software development.

A shared libary is a dependency. Dependencies can have a bad rep' because they have a tendency to lock-in your software agility. When you try to get out of that lock-in you will find that suddenly you have a "rogue implementation" which might not adhere to whatever that prior dependency exposed - but your implementation will be free.

A general rule, and a good one, is to have each service own its own implementation. But a lot of developers is really bad at coping with this on a mental level, because they believe shared code is about reuse. But when a dependent service cannot reuse due to perhaps a small tweak, that dependency can either become irrelevant or grow (because now it must also adhere to that little tweak).

So services which has the same dependency most often "locks" the dependency because know its being used by things you have no control over, and no one can guarentee it will never evolve. But when it evolves it becomes more difficult to maintain - and this will most likely also cause challenges for dependent services.

A dependency often ends up growing bigger over time. Because it evolves. And then versions come around. Then breaking changes. And then new dependencies come around. So dependencies becomes centerpieces of your services - and that is not what you want.

Remember the rule - the service owns its implementation. Especially DTO's because they are likely to not be stale over time. Especially in the beginning of a software project!

Another thing I have seen over and over again, is that DTO properties are very rarely reused to the fullest.

One service might want to use the FullName property where another service only needs the Email of a DTO. That's not reuse. That's a different need. Hence DRY does not apply. DRY is only about 100% reuse!!!

Also, the DRY principle is great but remember service domain contexts and where the responsibility lies.