Data Transfer Objects Between Microservices

microservices scaled 1

IT Tips & Insights: Should you share DTOs — and if so, which method is best? A Softensity software engineer shares his expertise. 

By Yoel Rivera, Software Engineer

Those immersed in software development constantly seek to do things better, which often implies making difficult decisions, and sometimes making technical and business sacrifices. Some time ago, I was studying distributed microservices, and I came across a problem that you will most likely encounter when communicating microservices.

Services must interact using an interprocess communication protocol such as HTTP, AMQP, or a binary protocol such as TCP, depending on the nature of each service. They also require transferring information between them, regardless of the format used for communication, such as JSON, XML, etc., generated from Data Transfer Object (DTO).

These DTOs are often the same across the different services that interact. For example, in the case of an order microservice and a customer microservice, they share OrderDTO.

Should We Share DTOs?

The question here would be, should we share DTOs? Best practices indicate that a microservice should be as autonomous and independent as possible, and they may even be developed in different technologies and languages. The answer to this question is relatively simple. I will present some options that I found, and you can evaluate which one best suits the circumstances of your projects.

Option 1: Share Your Layer of DTOs as a Package

This option consists of creating a project that contains the DTO classes. For example, in the .Net Framework case, it would be a Dynamic Link Library (DLL). This project generates a packaged file that can be used by microservices that require it by setting a dependency.

Advantages:

  • There is no duplication of code
  • DTO classes are written only once
  • Easy maintenance

Disadvantages:

  • Direct dependency between microservices
  • Microservices must be developed with compatible technology to include packaging

There are other alternatives similar to this one, but the common factor among them is that they create a dependency between the related microservices.

Option 2: IDL (Interface Description Language)

Option two consists of each microservice exposing in the form of a schema (WSDL and WADL) the structure of the DTOs, including the services it contains. Although this was indeed used more regularly when using SOAP, when using REST with JSON, it is possible to create a schema with which you can obtain a description of the messages. Some tools can be useful in this regard, such as Swagger and JSON Schema, among the most common.

Advantages:

  • Easy access to message format and features
  • Microservices can be developed on different technologies

Disadvantages:

  • Indirect dependency between microservices
  • Requires microservices to be documented

Option 3: Do not share the DATA

If you do not share the DATA, each microservice must remain isolated and must implement its layer of DTOs to be able to map the messages.

Advantages:

  • Microservices can be developed on different technologies
  • The DTOs classes can be more customized to what each microservice requires
  • Absolute independence between microservices

Disadvantages:

  • There is duplication of code
  • Complex maintenance if there were changes in the DTOs layer

These are the three options generally used. It’s up to you to analyze the options and choose the one that suits you best. Personally, the one I have used the most is option three since, although it is more laborious, it keeps the microservices independent.

About

Yoel Rivera is a Full Stack Developer specializing in .Net technologies. He has more than 12 years of experience working on dynamic projects in all stages of the development cycle. Yoel is well-versed in numerous programming languages, including C#, HTML5, Angular, Java, JavaScript, CSS, SQL Server, and MySQL. He also has a strong background in scrum methodology and customer relations.

Join Softensity’s Team

References

Microsoft Developer Division. (2022). NET Microservices Architecture for Containerized NET Applications. Microsoft Web Site: https://dotnet.microsoft.com/en-us/download/e-book/microservices-architecture/pdf

Eduardo Patiño. (2020). Microservicios con net core 3 hasta su publicación en azure. 2022, May 26, de Udemy Web Site: https://www.udemy.com/course/microservicios-con-net-core-3-hasta-su-publicacion-en-azure

Baeldung. (2021). How to Share DTO Across Microservices. 2022, May 26, de Baeldung Web Site: https://www.baeldung.com/java-microservices-share-dto?ref=morioh.com&utm_source=morioh.com

Ashan Fernando. (2019). The Dilemma of Code Reuse in Microservices. 2022, May 26, de Bits and Pieces Web Site: https://blog.bitsrc.io/the-dilemma-of-code-reuse-in-microservices-a925ff2b9981