Comments 9
Это разве не чистая архитектура? Контроллер - Use Case - Сервис - Сущность.
Интересней в примере получение данный в DTO - например из сервиса/queryBus в DTO
Спасибо за статью. Но не удержусь от пары замечаний.
Ошибку валидации вряд ли нужно логировать. Это, по сути, не ошибка, а совершенно ожидаемое поведение. Да, там останется только перевыброс исключения. И как раз на этом стоит остановиться поподробнее
Код не станет сложнее, если Exception поменять на ServiceValidationException и DomainValidationException, но зато станет куда более логичным и приближённым к реальности. А сейчас смотришь, и не понимаешь, почему ошибка, к примеру, соединения базы данных возвращает 400, а не 500 статус
И вот тут как раз и объяснить, почему вы меняем DomainValidationException на ServiceValidationException
Ну и совсем уж по мелочи
ошибку "Не корректная сумма денег" надо заменить на "Некорректная валюта" (и в целом надо бы вычитать на грамматические ошибки и опечатки)
проверка на empty($this->value) не имеет смысла, её стоит убрать
Насчет замечания по поводу исключений - такой подход так же имеет место быть. Я же хотел - как можно максимальнее сосредоточить статью на DTO и VO. Что бы все внимание досталось именно им.
Что же касается - логирования - в текущем контексте - это был лишь инструмент для того, что б показать абстрактный пример обработки исключения на одном из слое. Возможно нужно было - подобрать немного иную абстракцию.
'empty' поправил(убрал) - спасибо, Вы правы)
Проблемы: много параметров,
Это не такая уж и проблема, особенно учитывая то, что для создания DTO вам нужно использовать точно такое же количество параметров. При этом, параметры функции SendMail1 точно так же отображаются в подсказках IDE, как и подсказки функции __construct класса ClientMailDTO.
if ($this->currency !== 'USD' || $this->currency !== 'RUB') {
А здесь есть другое решение - Enum с нужными валютами. При этом IDE будет подсказывать, какие варианты допустимы в качестве параметра функции.
ValueObject - неудачное название. Под этим часто понимают класс с единственным полем value (часто даже публичным), смысл которого - запретить сомнительные операции. Например, id часто представляет собой целое число, но это число - вещь в себе. Ни умножать ни складывать его ни с чем нельзя, но при этом можно сравнивать (т.е. вычитать с отбрасыванием результата). Вот здесь и нужен тип IntValue, который при этом умеет сериализовываться / десериализовываться в число.
Насчет название и смысла - так может показаться, если прийти к ValueObject через интуицию(то есть не прибегая к специализированному материалу).
Например логика может быть такая: переводится как объект значение - ну тут все понятно)) Пойду кодить)))
Что же касается смысла, причин использования и примеры на мой взгляд интересных реализаций - это можно подсмотреть в книге Вон Верон "Предметно-ориентированное проектирование". Там достаточно подробно это все описано.
Опять же это мое видение.
А что касается конкретного названия - смею предположить, что нужно было как то назвать этот подход и тут "Объект-значение" в контексте архитектурного подхода и в контексте синтаксиса выбранного языка программирование - может означать разный смысл.
В первом случае(контекст подхода) - это осмысление текущего объекта со стороны бизнес логики
Во втором случае(контекст синтаксиса ЯП) - можно предположить, как раз таки, что у объекта есть какое то значение и ни про какую бизнес логику или осмысление тут уже речь не идет.
И закончу ответ фразой: "Отвергаешь - предлагай". То есть, какое название с Вашей точки зрения - было бы удачное?
То есть, какое название с Вашей точки зрения - было бы удачное?
Ну, эээ, собственно DTO. Ну если мы про PHP, то в симфони например создать невалидную дтошку из запроса можно, с целью например потом подтянуть какие-то значения ещё откуда-то, но вот пробросить по шине и обработать невалидную дто уже нельзя, шина не пропустит.
Ну и надо различать валидацию (поле email содержит что-то, что выглядит как емейл) и верификацию (например, бизнес-логика требует, что этот емейл должен быть в БД, иначе сначала иди подтверди его через отправку письма с кодом).
Value object и DTO в PHP (DDD)