A really simple rule of thumb is that you should only use a DTO object when you need to ... transfer data. That means use a DTO at the boundaries in your web API, or when you are sending the object on a message bus. Internally, just use your domain objects.

The only reason a DTO should exist is the limitations of the (de)serialization layers. Those need simple objects without complex logic.

Recommendation:

• Use standard models in your services
• Convert the model to a DTO in the controller (i.e. in your web application) just prior to serialization.
• If you use asynchronous messaging, convert the model to a DTO just before pushing the DTO on the message queue

This allows you to use your services as you desire, and save the DTOs for when they are actually required.

A really simple rule of thumb is that you should only use a DTO when you need to ... transfer data. That means use a DTO at the boundaries of your web API, or when you are sending the object on a message bus. Internally, just use your domain objects.

The only reason a DTO should exist is the limitations of the (de)serialization layers. Those need simple objects without complex logic.

Recommendations:

• Use standard models in your services;
• Convert the model to a DTO in the controller (i.e. in your web application) just prior to serialization;
• If you use asynchronous messaging, convert the model to a DTO just before pushing the DTO on the message queue.

This allows you to use your services as you desire, and save the DTOs for when they are actually required.

A really simple rule of thumb is that you should only use a DTO object when you need to ... transfer data. That means use a DTO at the boundaries in your web API, or when you are sending the object on a message bus. Internally, just use your domain objects.

The only reason a DTO should exist is the limitations of the (de)serialization layers. Those need simple objects without complex logic.

A really simple rule of thumb is that you should only use a DTO object when you need to ... transfer data. That means use a DTO at the boundaries in your web API, or when you are sending the object on a message bus. Internally, just use your domain objects.

The only reason a DTO should exist is the limitations of the (de)serialization layers. Those need simple objects without complex logic.

Recommendation:

• Use standard models in your services
• Convert the model to a DTO in the controller (i.e. in your web application) just prior to serialization.
• If you use asynchronous messaging, convert the model to a DTO just before pushing the DTO on the message queue

This allows you to use your services as you desire, and save the DTOs for when they are actually required.