Decide what DTO design pattern class-validation is optimizing for

[ben-ryder]

In a project using class-validation I'm facing a design pattern decision/question about the use of "DTO" classes.

Right now in that project DTO classes exist and are used to describe & validate request data. The same DTO classes are also used to describe the data passed from controllers -> business logic services -> database services.

The issue is my request data shape is now diverging from the data shape required by the database service. This means I now need multiple "DTO" classes for a single action:

• one for validating request data at the controller layer and describing the interface between the controller and business logic service
• one for describing the interface between the business logic layer and database service layer

This is fine, but I'm finding it somewhat confuses the use of the phrase "DTOs". My solution so far has been to now have a distinction between "shapes" and "dtos":

• "Shapes" are classes defining the request data shape and are decorated with class-validator decorators
• "DTOs" are classes that are purely for transferring data

None of this really relates to class-validation too much, however I'm thinking that it could be worth while removing all references to "DTOs" from class-validation.