How to properly convert domain entities to DTOs while considering scalability & testability

Solution 1: Private method in the service layer for converting

I guess Solution 1 will not not work well, because your DTOs are domain-oriented and not service oriented. Thus it will be likely that they are used in different services. So a mapping method does not belong to one service and therefore should not be implemented in one service. How would you re-use the mapping method in another service?

The 1. solution would work well if you use dedicated DTOs per service method. But more about this at the end.

Solution 2: Additional constructor in the DTO for converting domain entity to DTO

In general a good option, because you can see the DTO as an adapter to the entity. In other words: the DTO is another representation of an entity. Such designs often wrap the source object and provide methods that give you another view on the wrapped object.

But a DTO is a data transfer object so it might be serialized sooner or later and send over a network, e.g. using spring’s remoting capabilities. In this case the client that receives this DTO must deserialize it and thus needs the entity classes in it’s classpath, even if it only uses the DTO’s interface.

Solution 3: Using Spring’s Converter or any other externalized Bean for this converting

Solution 3 is the solution that I also would prefer. But I would create a Mapper<S,T> interface that is responsible for mapping from source to target and vice versa. E.g.

public interface Mapper<S,T> {
     public T map(S source);
     public S map(T target);

The implementation can be done using a mapping framework like modelmapper.

You also said that a converter for each entity

doesn’t “scale” that much as my domain model grows. With a lot of entities I have to create two converters for every new entity (-> converting DTO entitiy and entitiy to DTO)

I doupt that you only have to create 2 converter or one mapper for one DTO, because your DTO is domain-oriented.

As soon as you start to use it in another service you will recognize that the other service usually should or can not return all values that the first service does.
You will start to implement another mapper or converter for each other service.

This answer would get to long if I start with pros and cons of dedicated or shared DTOs, so I can only ask you to read my blog pros and cons of service layer designs.


About the third solution: where do you prefer to put the call for the mapper?

In the layer above the use cases. DTOs are data transfer objects, because they pack data in data structures that are best for the transfer protocol. Thus I call that layer the transport layer.
This layer is responsible for mapping use case’s request and result objects from and to the transport representation, e.g. json data structures.


I see you’re ok with passing an entity as a DTO constructor parameter. Would you also be ok with the opposite? I mean, passing a DTO as an Entity constructor parameter?

A good question. The opposite would not be ok for me, because I would then introduce a dependency in the entity to the transport layer. This would mean that a change in the transport layer can impact the entities and I don’t want changes in more detailed layers to impact more abstract layers.

If you need to pass data from the transport layer to the entity layer you should apply the dependency inversion principle.

Introduce an interface that will return the data through a set of getters, let the DTO implement it and use this interface in the entities constructor. Keep in mind that this interface belongs to the entity’s layer and thus should not have any dependencies to the transport layer.

 +-----+  implements     ||   +------------+   uses  +--------+
 | DTO |  ---------------||-> | EntityData |  <----  | Entity |
 +-----+                 ||   +------------+         +--------+

Leave a Comment