Подтверждение регистрации

Комментарии (14)

Denis

2020-01-27 19:33

Я немного не понял зачем в конструкторе по умолчанию ставить статус? А если мне потребуется из массива заполнить класс User данными? Получается, что статус будет не активный, но а пользователь на самом деле активен. Т.е. через конструктор я не смогу указать текущий статус? Поясните, пожалуйста, в чем дело.

Дмитрий Елисеев

2020-01-27 20:57

А если мне потребуется из массива заполнить класс User данными?

Конструктор используется по назначению только для первого создания объекта. Как и другие методы он содержит свою бизнес-логику, по которой может присваивать первоначальные значения, бросать исключения и генерировать события.

В случае же восстановления объекта по массиву из БД конструктор не используют. Вместо этого объект там создаётся без конструктора и заполняется данными прямо в приватные поля через рефлексию.

Например, пишем гидратор или находим любой готовый вроде такого:

class Hydrator
{
    public function hydrate(string $class, array $data): object
    {
        $reflection = new \ReflectionClass($class);
        $target = $reflection->newInstanceWithoutConstructor();
        foreach ($data as $name => $value) {
            $property = $reflection->getProperty($name);
            $property->setAccessible(true);
            $property->setValue($target, $value);
        }
        return $target;
    }
}

и с помощью него десериализуем объект текущими данными из БД:

$row = $stmt->fetch(PDO::FETCH_ASSOC);

$user = $this->hydrator->hydrate(User::class, [
    'id' => new Id($row['id']),
    'status' => new Status($row['status']),
]);

Если же нужно просто в разных юзкейсах создавать объект по-разному, то в этом случае можно сделать несколько именованных конструкторов, как мы делали в видео о конструкторах. В будущем эпизоде про регистрацию через соцсети мы сделаем именно так.

Denis

2020-01-28 06:54

Спасибо за ответ. Сегодня обязательно видео посмотрю.

Сергей

2020-02-12 07:50

Всем привет. Дмитрий, добрый день. Вот у меня такой вопрос возник. У нас хендлеры не могут быть описаны каким-то единым интерфейсом, т.к. на вход принимают разные команды. Точнее можно сделать команды , реализующие некий интерфейс или унаследованные от какой-то абстрактной команды, но тут уже будет какой-то костыль.

И вот у меня возникла потребность задекорировать все хендлеры, добавив логирование начала и конца работы каждого хендлера. Как-то это можно реализовать без костылей?

Дмитрий Елисеев

2020-02-14 06:55

В языках с дженериками можно указать общий интерфейс.

interface Handler<T> {
    public void handle(<T> command)
}

В PHP без шаблонов это пока не работает.

В любом языке можно сделать свой интерфейс CommandBus для запуска команд и декорировать уже шину. В PHP можно взять league/tactician и реализовать логирование через middleware в ней.

Сергей

2020-03-20 09:11

Не подскажете еще как быть с автовайрингом? Пытался внедрить симфонячий мессенджер. Указал в конфиге

MessageBusInterface::class => static function (ContainerInterface $container): MessageBusInterface {
    return new MessageBus([
        new HandleMessageMiddleware(new HandlersLocator([
            EmissionCommand::class => [$container->get(EmissionHandler::class)],
            TransferCommand::class => [$container->get(TransferHandler::class)],
        ])),
    ]);
}

Но если в хендлер внедряется MessageBusInterface, то получается Circular dependency. И вот что-то ума не приложу как эту беду победить.

Дмитрий Елисеев

2020-03-20 13:24

Переделать Locator на доставание хендлера только по требованию:

new HandlersLocator([
    EmissionCommand::class => EmissionHandler::class,
    TransferCommand::class => TransferHandler::class,
], $container)

Сергей

2020-03-20 14:52

Спасибо, Дмитрий. Пришлось переписать локатор и всё заработало.

Евгений

2020-09-04 04:45

Дмитрий, вы показали как вынести в отдельный класс операции со статусами.

Но есть ещё несколько часто используемых операций:

Сериализация статуса в код и обратно
Текстовое название статуса. Получение по коду статуса.
По названию получить код (для обработки форм с Тильды пришлось такое добавить)
Список доступных статусов (код => название)

Как бы вы решили такую задачу в рамках DDD ?

Дмитрий Елисеев

2020-09-09 07:31

Обычно название статуса нужно только для отображения на фронтенде. Домену интересен только код. Поэтому все эти преобразования будут только снаружи в контроллерах или в файлах переводов. Поэтому если для сериализации используется пакет вроде symfony/serializer, то для статуса легко пишется кастомный сериализатор.

Ivan

2020-09-26 18:01

Почему мы не используем mock в unit тестах? Когда вообще надо использовать мок? Нафига он нужен в принципе?

Дмитрий Елисеев

2020-09-27 12:39

Моки и стабы будут в 17-ом эпизоде, когда с их помощью нужно будет имитировать зависимости.

Ivan

2020-09-27 08:45

public function confirmJoin(Token $token)
{
    if (is_null($this->joinConfirmToken)) {
        throw new DomainException("User has already been confirmed!");
    }
    $this->joinConfirmationToken->validate($token);
    $this->status = Status::active();
    $this->joinConfirmationToken = null;
}

if (is_null($this->joinConfirmToken)) - такого не может быть ведь мы в Сommand ищем юзера по токену

Как мы дойдем до "User has already been confirmed!" если в этом случае токен null, а мы ищем юзера по токену?

Не является ли это логической ошибкой? Дмитрий

Дмитрий Елисеев

2020-09-27 12:54

Сейчас confirmJoin мы используем только в обработчике команды, поэтому проверка выглядит избыточно. Но скоро начнём его вызывать в UserBuilder и в фикстурах для заполнения БД демо-данными для разработки и для тестов. И тогда появятся проблемы, если такой проверки у нас не будет.

Поэтому любому методу должно быть всё равно, откуда и как его вызывают выше. Все проверки в нём должны быть всегда.

Зарегистрируйтесь или войдите чтобы оставить комментарий