Microservices – Sharing DTO Objects Between Microservices

dtojavamicroservices

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?

Best Answer

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.

Related Topic