Use Cases модуля аутентификации

Спасибо. Очень интересно.

Спасибо, Дмитрий! Хотел бы посмотреть в вашем исполнении на реализацию подобной ситуации: пользователь регистрируется в контексте аутентификации с ролью покупателя, в контексте покупателей также создается сущность с данными покупателя. Эти данные относятся только к предметной подобласти покупателей ( и не относятся к контексту аутентификации ). Ситуация гиппотетическая. Ну и вообще очень интересно было бы посмотреть на различные вариации интеграции ограниченных контекстов.

Спасибо. Хотелось бы чуть сторонней информации о процессе "проверка приложения" на Facebook. И еще предположим, что нам ТРЕБУЕТСЯ майл пользователя, а Facebook API не всегда его предоставляет, выдает токин и всё, что будем делать в таком случае?

Заметил, что изменение скорости воспроизведения видео не работает. Смотрю с мобильного браузера chrome android

Непонятно почему DTO назвали Command, ведь Command должен что-то изменять, а DTO объект просто содержит данные.

будет ли очередь (Rabbit или Queue) ?

Если именование Handle ещё не очень критично, так как мы его фактически нигде не вызываем, обычно это command bus, то вот с Command все сложнее. По всему коду и тестам у нас будут new Command(), чтобы понять что это за команда, надо либо полезть в use, либо делать в use алиас, либо перейти в класс команды. Всё это неудобно. Не лучше ли избавиться от папки c названием команды и перенести это в название класса, например, JoinByEmailRequestCommand, JoinByEmailRequestHandler. С одной стороны длинные названия классов, но с другой стороны в сто раз код читабельнее становится

Очень полезный урок, спасибо.

Хотелось бы узнать а как транзакции реализуются при таком подходе, предположим зарегистрировали пользователя (пользователь нужен сразу в контексте авторизации, автора и покупателя), это посути записи в три отдельных контекста.

Пользователь валидный только если он присутствует во всех трёх контекстах одновременно (по разным причинам).

Нам по сути по одному действию (регистрации) нужно кинуть три команды сразу. Две у нас выполняется, третья крашится. По условию пользователь не валидный, что делать в таком случае? В транзакцию это дело не завернешь, ну и две предыдущие нужно откатить как то ?

Спасибо за уроки. Появилось пару вопросов. "Модуль" Auth это конекст из ддд терминологии? Содержимое папки Commands это Application Services или Domain Services?

Дмитрий, скажите, пожалуйста, если проект у нас полностью на yii2 (advanced) : frontend, backend, api - тогда CQS оставляем в папке апи, а сущности выносим в какую-нибудь папку, например, auction? То есть структура будет такой:

• backend
• frontend
• api > auth > command
• name_project > auth > Entity

Верно размышляю?

Кстати. Дмитрий. Нашел очень хороший сервис Auth0 бесплатный тариф до 7000 АКТИВНЫХ пользователей. Отлично подходит на микросервисы. Почему не использовать бы его в своих проектах и не писать каждый раз свой Auth. Понимаю, что мы учимся и Auth может быть со своими требованиями, но не плохой сервис как по мне. Что скажете?)

Здравствуйте) Последняя тенденция модуль Auth называть Id (Identity). Например, Сбербанк ID, DeworkerPro ID. Может быть в этом проекте тоже назвать данный модуль так? Или я не так понимаю? Заодно будет ролик про то, когда меняется что Глобальное)

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

Спасибо, отличный материал

На основе этой архитектуры планирую сделать телеграм бот на node js (telegraf.js).

То есть человек заходить отправляет токен бота и ему поднимается телеграм бот новый инстанс

через React админку можно включать и отклать этот бот. Как лучше реализовать ?

Немного не понял про Use Case. Это же по сути сервис? Т.е с тем же успехом можно было сделать сервис хранящий бизнес-логику, или я что-то путаю?

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

Я хочу переделать свой проект, не могли бы вы мне подсказать как можно поступить.

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

У меня есть сделка и по ней есть разные операции - покупка, продажа и т. д.

По каждой операции нужно пробивать бухгалтерские проводки и генерировать документы

Я вижу два решения:

Решение 1.

Мне нужно создать контекст - операции по сделке

В нем создать 2 сервиса - сервис документов для генерации документов и сервис бухгалтерии для пробития проводок.

И в рамках юзкейса к примеру "Продажа товара", мы будем эти два сервиса использовать.

Решение 2.

Мы отдельно выделяем контекст(модуль) для бухгалтерии в котором описываем всю логику бухгалтерии - не только пробитие проводок, но и генерацию отчетов к примеру, тоже самое делаем с документами.

Далее создаем отдельную папку с usecases, в которой будут описаны операции по сделке и эти операции будут дергать нужные модули контекстов, например модуль бухгалтерии и модуль генерации документов.

Что думаете?