Should Value Objects be used inside the DTO?

Question

After reading about Value Objects, I think they're pretty cool and should be used, but I am not sure if I am doing it the right way.

Let's assume that I have a simple DTO to create a user, which contains information that should be validated (e.g., the email must be valid, the birthdate cannot be in the future, etc.) from a technical point of view. At the same time, I have a business requirement such as the user can't be younger than 14 years old, and I don't think that hardcoding this into the Birthdate class is a good idea. I think it would be better to move this validation to another service.

public class CreateUserPayloadDto {
  @JsonPropery("email")
  Email email; // user's email
  @JsonPropery("birthdate")
  Birthdate birthdate; // user's birthdate
}

If I use Value Objects in the DTO, I can't test negative cases properly (for example, if the birthdate is in the future, then BAD REQUEST must be returned).

I have come up with three solutions:

• Do not use Value Objects but use Java Bean Validation (then convert it to a POJO with Value Objects inside).
• Use Value Objects and do not write tests for negative cases.
• Create a separate DTO that uses primitives but is the same as the DTO with Value Objects, and test it this way. See example of code below

public class CreateUserPayloadDto {
  @JsonPropery("email")
  String email; // user's email
  @JsonPropery("birthdate")
  String birthdate; // user's birthdate
}

If you need more info, I will provide it as soon as I can. Thank you!

UPD:

Here is an example of my integration test:

@SpringBootTest
@AutoConfigureWebTestClient
public CreateUserEndpointTest {

  @Autowired
  WebTestClient webTestClient;

  @Test
  public void shouldReturn400BadRequestIfBirthdateIsInTheFuture() {
    final CreateUserPayloadDto body = CreateUserPayloadDto.builder()
          // I can't do this, because Birthdate cannot be instantiated 
          // since it is invalid!
         .birthdate(Birthdate.of(LocalDate.now().plusYears(1)))
         .build();

    final WebTestClient.ResponseSpec responseSpec = sendRequest(body);
    
    responseSpec.expectStatus().isBadRequest();
  }
}

Answer 1

VO, DTO, POJO this is a joggling between terminology in the end they are just encapsulations for transferring data. If there are getters involved then it is about value object (VO), if the transfer it is over the network then it is about data transfer object (DTO), if there it is a random data container (without getters and setters) then it is about plain old java object (POJO), thus wrap value objects into data transfer objects to transfer information over the network.

To talk about the validation there are two different validations: data integrity and data consistency. In a web application the layer receiving requests validates data for integrity (e.g. data sent for age is numeric), the layer processing the request validates data for consistency with the application business(e.g. age it is at least fourteen) and the layer persisting data validates data for persistence environment integrity (e.g. the data to be persisted contains just information that could be persisted by the persistence environment. Applied to database persistence that would be using prepared statements that transparently ensure information validity).

When in doubt avoiding using well known terminology while thinking about what needs to be done and things start to get simpler.

Answer 2

If you are able to use your value objects with thier built in validation on the client side of the DTO it begs the question of why you have a DTO at all.

The purpose of a DTO in this case would be to send raw unprocessed data needed to create a object to the backend for validation and transformation into that object.

But it seems like you could just do all that client side and send the competed User object, validation and processing already done to the server for persistence if required at all.

On a side note, using a value object to restrict a date range like this is probably not a great idea. Its going to rely on you injecting the current date somehow and obviously the validity of the object can change while the data is at rest, as time progresses.