Где будет проверка если например у нас есть бизнес правило уникальный ИНН компании? Это частая упущение учебных примеров. В данном случае делать в юзкейсе не правильно
15:38 - Я не знаю какой контингент слушателей этой лекции, но мне кажется это странный способ объясненить понятие. "одноразовая штука, которую бросили и забыли...". Может люди хотели услышать определение от живого человека, а не от справочника. Но на мой взляд здесь нет ни слова определения что такое DTO и почему мы его используем.
До дто досмотрел, дальше уже не было желания смотреть. "препод" нихера не объяснил в чем разница между value object и dto, а просто сказал, что (по его мнению) такое дто и все. Причем перед этим то же самое говорил по сути и про value object
Надеюсь вам еще актуально. Разница в том, как я понял, что DTO используется для перемещений данных между слоями на верхнем уровне. Грубо говоря у нас есть слой с контроллерами и слой с сервисом, и мы не можем перемещать данные между сервисом и контроллером с помощью VO так как мы перепрыгиваем через слой. VO используется внутри чистой бизнес логики: контроллеры не ее часть.
DTO это объект для передачи вашего энтити, т.е. когда ваш entity нужно передать между слоями, сервисами и т.д. вы его пакуете в ДТО. У DTO есть уникальный идентификатор. VO это просто значение, как число или строка, просто в виде объекта. У VO не может быть уникального идентификатора. Например купюра в 100 долларов. Если вам важно различать конкретные купюры в 100 баксов (например, вы коллекционер), вы собираете только купюры у которых номер начинается на "5" то для вас разные купюры в 100 долларов, будут разными entity, а DTO будет описывать схему для передачи данных об этих купюрах. И ДТО будет содержать номер каждой купюры. Если вы, например, кассир, то вам не важная конкретная купюра, вам важен только ее номинал в 100 баксов. Это будет VO. И да, dto не может содержать методов, так как он только для передачи свойств.
