Регистрация пользователей и тесты

спасибо

Дмитрий, спасибо! Не планируете ли рассмотреть подход с валидацией всех данных сущности отложено, чтобы, к примеру, дать более информативный ответ пользователю о том, какие данные были введены неверно. К примеру М. Фаулер писал о неком Шаблоне Увеломления ( Notification Pattern ) ( https://martinfowler.com/articles/replaceThrowWithNotification.html, https://martinfowler.com/eaaDev/Notification.html, . В текущем подходе, при модификации данных сущности, исключение будет выброшено при обнаружении первого невалидного аргумента. До остальных проверок не дойдет и пользователь не узнает, что он где-то еще мог допустить ошибку при вводе данных.

Не является ли использование флашера отдаленной привязкой к Doctrine, ведь не все библиотеки для работы с БД работают по такой схеме? И является ли использование флашера вообще правильным, ведь мы отправляем в БД сразу вообще все изменения, о которых наш Handler даже может и не знать. Мне кажется, что сохранять в БД нужно уже в репозитории, причем весь агрегат вместе с дочерними сущностями (например user, user_profile) и только их и внутри транзакции, а не всё, что накопил EM. Что думаете?

Дмитрий, Вы выбрали использовать простые типы данных в командах, преобразуя их в DTO уже в Handler. Я видел еще 2 варианта, кто-то сразу в команду передает DTO, кто-то передает в команду простые типы и в конструкторе делает DTO. Никак не могу понять, есть ли какая-то разница кроме вкусовщины?

Да-да, я про VO, прошу прощения)) В таком случае можно инициализировать в команде, это разгрузит код хэндлера

А может быть уже есть библиотека, в которой определены сущности Entity? Email и т.п.

Здравствуйте.

В ваших роликах, при проектировании, сущности всегда встречал повторяющиеся Value Objects: ID, Status, Role, Name, Email.

Каждый раз, при проектировании какой-либо сущности, вы копируйте ID, который является UUID. И таким образом мы получаем копипасту, в тестах и сущностях.

Если в наших проектах Status, Role, Name как-то может поменяться, то ID и Email никогда не меняется. Таким образом его можно вынести в отдельную папку Value Object и использовать от туда. Но вы этого не делаете. Почему?) вместо этого у вас ID на каждую сущность. Можете пояснить по этому вопросу?

И ещё один вопрос «является ли status, role» VO?

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

Очень похоже на ваш доклад с PhpRussia 2019 )

Кто-нибудь желает добавить к видео субтитры? Потому что я не понимаю по-русски.

А если бы мы хешировали пароль по старинке с помощью соли, то нужно было бы ее передавать вместе с $passwordHash в requestJoinByEmail и везде добавлять проверки $salt !== null, там где есть $passwordHash !== null? Или можно как-то более интереснее поступить?

а я что-то не понял момент, почему в классе Token мы приводим euid в нижний регистр (хотя он вроде и так всегда в нижнем), но вопрос в том почему в юнит тесте этого класса мы проверяем обычный euid, не приведен в нижний регистр?

Не подскажите, какую версию Uuid , чтоб генерировались более менее отсортированные Uuid. (У меня миллионы записей, поэтому мне интересно) Чуть странно, что ваши курсы рассчитана на аудиторию выше среднего, а тут взяли и сказали , что у нас будет маленькое приложение :)

За урок отдельное спасибо.

А почему UUID передается "извне". Почему бы его в конструкторе не создавать?

Дмитрий, а почему

throw new DomainException('User already exists.')

находится в usecase, если это правило доменной сущности? То есть если в системе появится место, где еще раз используется requestJoinByEmail, то про такую проверку разработчик может в теории забыть, хотя эта проверка очевидно должна быть обязательной для всех операций, связанных с запросом на регастрацию по email

На классе Email я кайфанул. Спасибо за инсайт

по sender-у на емайл в JoinByEmail/Request/ а не лучше Event сделать ?

Дмитрий, Скажите пожалуйста: А где лучше делать обработку исключений, например на не корректную строку ? Например если я вызываю команду сервиса - то как мне правильно обработать исключения?

В контроллере?

Благодарю Дмитрия за его труд. И хочу высказать свое мнение по поводу передачи в конструктор класса большого числа переменных. Но ведь можно пойти и другим путем. Просто использовать сеттеры. Иначе зачем их тогда прописывать. И тогда отпадает необходимость все или многие параметры оборачивать в объекты. Лично у меня возникает дискомфорт при создании дополнительных сущностей без которых можно обойтись. А потом для этих сущностей приходится писать конвертеры для доктрины. Это только мое лично мнение, и не критика подхода Дмитрия.

Дима, ребята, привет.

Мне кажется такой подход:

$this->users->add($user); #UserRepository
$this->flusher->flush();

Нас сильно привязывает к инфраструктуре.

Допустим у нас есть другой компонент, комментариев. Там будет тоже самое.

$this->comment->add($comment);  #CommentRepository
$this->flusher->flush();

И везде будет то же самое.

Почему бы нам не инкапсулировать необходимость вызова ->flush(); в Отдельный объект что-то вроде:

class FlushFlag
{
    private static bool $needFlush = false;
    private EntityManagerInterface $em;

    public function __construct(EntityManagerInterface $em)
    {
        $this->em = $em;
    }

    public static function needFlush(): void
    {
        self::$needFlush = true;
    }

    public function flush(): void
    {
        if (self::needFlush()) {
            $this->em->flush();
        }
    }
}

И потом вызывать его методах ->add(...) в репозиториях:

FlushFlag::needFlush();

где это нужно...

Удалить $this->flusher->flush(); в командах..

Затем в Middleware только в одном месте получить FlushFlag через DI в конструкторе и выполнить:

$this->flushFlag->flush();

Тем самым мы уберем зависимость от инфраструктуры (в данном случае от выбранной ORM) и инкапсулируем ее особенность в той же инфраструктуре в виде Middleware...

И, например, если мы захотим хранить юзеров в файлах, нам нужно будем менять только репозиторий (UserRepository), инфраструктуру, не трогая бизнес логику (не надо удалять везде где используется UserRepository строку $this->flusher->flush(); ) + уберем зависимость от Flusher в наших Command.

Столкнулся с такой проблемой, сделал свой тип поля для доктрины Status как у вас и в методе convertToPHPValue мы возвращаем return !empty($value) ? new Status($value) : null;

Но статусы могут быть не только у User, но и у других сущностей, и они могут иметь как общие статусы, типа active, inactive, так и для разных сущностей специфические

UserStatus active inactive

HouseStatus active inactive send new

WorkStatus active trainee fired

создавать под статусы разных сущностей отдельные типы полей в доктрине показалось too match, в то же время в методе convertToPHPValue у нас нет никакого понимания, какой тип статуса вернуть, какие есть варианты решения этой проблемы?

Добрый вечер. По поводу класса Id. В нём используется __toString(). Решил немного побаловаться rector-ом. При проверке класса Id получил такую рекомендацию.

 -class Id
+class Id implements \Stringable
  {
     public function __construct(
     private readonly string $value
----------- end diff -----------

В документации написано следующее

Интерфейс Stringable обозначает класс, реализующий метод __toString(). В отличие от большинства интерфейсов, Stringable неявно присутствует в любом классе, в котором определён магический метод __toString(), хотя он может и должен быть объявлен явно.

Нужно ли следовать этой рекомендации?