Всем привет. Ситуация: разрабатываю API, и для каждого запроса у

меня есть DTO класс. В этом классе описаны constraints и свойства - больше ничего там нет.
Конкретный пример: у меня есть CreateCodeFromPhoneRequest, в котором есть лиш поле phone. Когда запрос был успешно провалидирован, он попадает в action контроллера. Дальше стоит задача создать новый entity Code з этого телефона - его создание я хочу вынести отдельно в сервис.
Вопросы:
1) правильно ли будет, чтобы метод для создания нового CodeEntity принимал что-то на подобии CodeDTO, в котором будет описана структура Code? С другой стороны этот CodeDTO будет иметь те же свойства, что и CodeEntity. Этот CodeDTO я буду могу создавать з того же CreateCodeFromPhoneRequest, или еще другого места.
2) если подобный подход имеет место, то должен ли я дополнительно делать валидацию в CodeDTO?(описать все constraints)? Если да - в такому случае CodeEntity вобще не должна иметь никаких constraints, верно?

Идея в том что рано или поздно структура твоих DTO будет отличаться от структуры твоих сущностей. Идея в том что бы отделить интерфейсы от модели данных используемой для логики приложения. Сущности не должны валидироваться, они простот должны быть валидными. То есть проверки в конструкторе например и исключение если пришла какая-то хрень. Валидация на уровне бизнес логики имеет другие цели нежели валидация на уровне UI (DTO). Последнее - сказать юзеру где он не прав. А в бизнес логике недопустить неконсистентного состояния. Пусть тебя не смущает что будут похожие структуры - это не дублирование поскольку назначение у этих структур разное.

А если не секрет можно пример кода этого дто? Сам разрабатывать стал недавно, не совсем понимаю о чём речь :)