- Deworker
- База знаний
- Разработка аукциона на Slim и ReactJS
- Use Cases модуля аутентификации
Use Cases модуля аутентификации
Анализ Use Cases взаимодействия с модулем аутетнификации. Выделение команд Command и запросов Query. Принцип CQS разделения операций.
Чтобы не пропускать новые эпизоды подпишитесь на наш канал @deworkerpro в Telegram
- 1 Структура проекта Free
- 2 Почему именно микрофреймворк Free
- 3 Что есть Docker Free
- 4 Запуск и деплой сайта с Docker
- 5 Создание production-сервера c Ansible Free
- 6 Установка Slim и Symfony Console
- 7 Оптимизация Docker-образов
- 8 Xdebug для Docker в PhpStorm
- 9 PHPLint, CodeSniffer, Psalm
- 10 PHPUnit и Unit и Functional тесты
- 11 DDD и ограниченные контексты
- 12 Use Cases модуля аутентификации Free
- 13 Регистрация пользователей и тесты Free
- 14 Подтверждение регистрации
- 15 Регистрация через социальные сети
- 16 Восстановление пароля
- 17 Смена пароля и тесты с зависимостями
- 18 Смена Email с подтверждением
- 19 Смена роли и удаление пользователя
- 20 Подключение БД и выбор ORM Скоро
- 21 Отправка электронной почты Скоро
- 22 Написание и тестирование контроллеров Скоро
- 23 Валидация ввода Скоро
- 24 Аутентификация OAuth 2 Скоро
- 25 Установка и подключение ReactJS Скоро
- 26 Линтеры и юнит-тесты в JavaScript Скоро
- 27 Приёмочные тесты c Selenium в Docker Скоро
- 28 Философия CI, CD и CD Скоро
- 29 Доменная модель аукциона Скоро
- 30 ... Скоро
Спасибо. Очень интересно.
Спасибо, Дмитрий! Хотел бы посмотреть в вашем исполнении на реализацию подобной ситуации: пользователь регистрируется в контексте аутентификации с ролью покупателя, в контексте покупателей также создается сущность с данными покупателя. Эти данные относятся только к предметной подобласти покупателей ( и не относятся к контексту аутентификации ). Ситуация гиппотетическая. Ну и вообще очень интересно было бы посмотреть на различные вариации интеграции ограниченных контекстов.
Это вполне реальная ситуация, у покупателя куча полей, которые не нужны пользователю, например в битрикс так сделано, думаю Дмитрий поступит аналогично, когда дойдет до аукциона.
Спасибо. Хотелось бы чуть сторонней информации о процессе "проверка приложения" на Facebook. И еще предположим, что нам ТРЕБУЕТСЯ майл пользователя, а Facebook API не всегда его предоставляет, выдает токин и всё, что будем делать в таком случае?
Запрашивать почту дополнительно.
Это был намек на добавления этого процесса.
Заметил, что изменение скорости воспроизведения видео не работает. Смотрю с мобильного браузера chrome android
Непонятно почему DTO назвали Command, ведь Command должен что-то изменять, а DTO объект просто содержит данные.
Есть команда на изменение и её обработчик. Мы отправляем команду с описанием того, что нам нужно сделать. И система её выполняет. Такое именование используется в подходе с Command Bus, где команды даже могут сериализоваться и отправляться в очередь для выпонления в фоне.
Это не классический паттерн Command, где сам объект команды содержит методы execute() и undo(). У нас такой подход будет неудобен, так как обработчику понадобятся зависимые объекты и его конструктор будет ими занят.
будет ли очередь (Rabbit или Queue) ?
В описании курса написано "С WebSocket-интерактивом и очередями на RabbitMQ"!
да да, спс., незаметил ..:)
Если именование Handle ещё не очень критично, так как мы его фактически нигде не вызываем, обычно это command bus, то вот с Command все сложнее. По всему коду и тестам у нас будут new Command(), чтобы понять что это за команда, надо либо полезть в use, либо делать в use алиас, либо перейти в класс команды. Всё это неудобно. Не лучше ли избавиться от папки c названием команды и перенести это в название класса, например, JoinByEmailRequestCommand, JoinByEmailRequestHandler. С одной стороны длинные названия классов, но с другой стороны в сто раз код читабельнее становится
Можно как угодно. Становится читабельнее, но не писабельнее. А так да, если вдруг потребуется использовать две команды в одном классе (что вряд ли произойдёт), то можно использовать алиасы.
Очень полезный урок, спасибо.
Хотелось бы узнать а как транзакции реализуются при таком подходе, предположим зарегистрировали пользователя (пользователь нужен сразу в контексте авторизации, автора и покупателя), это посути записи в три отдельных контекста.
Пользователь валидный только если он присутствует во всех трёх контекстах одновременно (по разным причинам).
Нам по сути по одному действию (регистрации) нужно кинуть три команды сразу. Две у нас выполняется, третья крашится. По условию пользователь не валидный, что делать в таком случае? В транзакцию это дело не завернешь, ну и две предыдущие нужно откатить как то ?
Это делается через саги, подписываемые на доменные события.
Спасибо за уроки. Появилось пару вопросов. "Модуль" Auth это конекст из ддд терминологии? Содержимое папки Commands это Application Services или Domain Services?
Да, разбиваем на модули по контекстам. А горизонтальное разбиение такое: