When does encapsulating a primitive field into its own class make sense? [duplicate]

Let's say I have the following Java code: public record Person(String firtName, String lastName, int age) {} Can it makes sense to have instead: public record Person(FirstName firtName, LastName lastName, Age age) {} public record FirstName(String value) {} public record LastName(String value) {} public record Age(int value) {} I feel that there is no benefit to create those encapsulating classes but I have a colleague that disagree. Their logic is that it helps with documenting the code. I think it could make sense with Age, since there could be some logic associated with it (like computing date of birth), but for FirstName and LastName I think it is essentially useless and is just repeating the variable name. I'm looking for a general rule that could help determine when such a thing is useful or not.

May 21, 2025 - 20:20

Let's say I have the following Java code:

public record Person(String firtName, String lastName, int age) {}

Can it makes sense to have instead:

public record Person(FirstName firtName, LastName lastName, Age age) {}
public record FirstName(String value) {}
public record LastName(String value) {}
public record Age(int value) {}

I feel that there is no benefit to create those encapsulating classes but I have a colleague that disagree. Their logic is that it helps with documenting the code. I think it could make sense with Age, since there could be some logic associated with it (like computing date of birth), but for FirstName and LastName I think it is essentially useless and is just repeating the variable name.

I'm looking for a general rule that could help determine when such a thing is useful or not.