Создавать новую DTO или наследовать существующую при изменении типа данных
Что проверяют
Понимаете ли вы, что DTO это контракт передачи данных, а не место для иерархий наследования. И умеете ли вы думать не про красоту классов, а про обратную совместимость: кто читает этот JSON и что случится с ним после смены типа поля.
Как отвечать
Наследование DTO почти всегда плохой выбор. Полиморфизм в структуре данных не нужен, а побочные эффекты реальны: Jackson на иерархии требует явного @JsonTypeInfo, иначе форма ответа зависит от рантайм-типа; equals и hashCode при наследовании ломаются, и Lombok отдельно требует @EqualsAndHashCode(callSuper = true); читатель кода больше не видит полный набор полей в одном файле. Java record наследовать нельзя вовсе, и это лишний намёк, куда движется язык.
Дальше отвечать по границе. Если DTO внешний и у него есть потребители, смена типа поля это несовместимое изменение. Правильный путь: добавить новое поле рядом, старое пометить @Deprecated и какое-то время заполнять оба, а потом выпустить новую версию контракта с отдельным маппингом. Если DTO внутренний и живёт между двумя своими слоями, проще поменять поле на месте и поправить маппер и тесты. Композиция и общий вложенный объект лучше наследования, когда хочется убрать дублирование.
Где спотыкаются
Путают DTO с сущностью и предлагают отдать наружу JPA-entity. Получают ленивую инициализацию вне транзакции, лишние поля в ответе и жёсткую связку схемы базы с публичным API.
Наследуют, чтобы не переписывать поля, и через месяц ловят сюрприз сериализации или сравнения объектов. Экономия в пять строк оборачивается разбором, почему в ответе появилось поле, которого в спецификации нет.
Меняют тип поля прямо в существующем DTO и считают это безобидным. Мобильные клиенты старых версий продолжают ходить в тот же эндпоинт и падают на разборе ответа, а откатить уже нельзя. Хороший ответ обязан упомянуть версионирование и период, когда живы оба поля.