Не понял, что Вы хотели сказать.

В месте использования предпочтительнее работать с некоторой абстракцией над маппингом.

В этом и смысл использования библиотек. Все специфичные поля библиотека обрабатывает сама. Обработку неспецифичных полей никто кроме Вас не напишет.

Выходит тащим библиотеку для решение проблемы, в итоге получаем частичное решение проблемы + зависимости.

Поэтому, правильным решением является использование библиотеки-маппера.

Не могу согласиться. В данном примере код, завязанный на библиотеку тоже имеет ряд недостатков:

• Возможность конфликтов с другими библиотеками (несовместимость аннотаций)
• Нет гарантии, что после обновлении версии библиотеки не придется переписывать маппинг всех Entities, DTOs (breaking changes)
• Изменилось поле, напиши конвертер
• Опять не уйти от абстракции, чтобы скрыть реализацию. В сути получаем тот же «колхозный» ItemMapper на базе библиотеки.

Как решить проблему, если DTO имеет другую (схожую) структуру с Entity. Например в DTO вычислимое поле А, которое состоит из суммы полей B и C соответствующей Entity. Писать для каждого случая постконвертер (TypeMap)?

Конечно, если Entities толстые, может и имеет смысл использовать библиотеку. Но скорее всего проблема вытекает из другого места.

markitosha Коротко и по делу, спасибо. В повседневной практике сталкиваюсь с такого рода поведением младших сотрудников. С самыми простыми задачами всё достаточно прозрачно, а вот какое относительно оптимальное время на разбор более объемной задачи по алгоритму выше? С какой периодичностью вы интересуетесь статусом задачи?