SP
отправь чуваку письмо мол "сорян но вы вроде уже зареганы, если забыли пароль вот ссылка"
Size: a a a
2021 November 09
A
Ну пусть это будут одинаковые логины, а не емейлы
SP
в подавляющем большинстве случаев сложность такого подходя для "регистрации" того не стоит. В кейсе с бутылками уже не уникальность а экслюзивность. это другое
A
Ну такой себе ux
SP
в этом случае тоже самое. добавляем, смотрим дубли, если есть - меняем юзернейм и добавляем суфикс, уведомляем чела. eventual consistency
A
Так может это как раз кейс для сервиса?
SP
ну так у тебя ж скорее всего на UI была проверка занят email/username иил нет. Вот там весь твой UX.
SP
да, ток я не люблю "доменными сервисами" это называть.
A
Допустим нет
SP
ну тогда у тебя плохой UX в любом случае как бы ты не сделал)
A
wap 2.0 ¯\_(ツ)_/¯
A
А как называть?
SP
ну у меня такие вещи на ивентах (если юзер новый появился - проверить юзернейм и поправить если че не так) - я такие вещи называю политики (policy)
SP
они же process managers по сути ток более общее название
SP
SP
p.s. это далеко не единственный вариант такое сделать просто оч хорошо ложится на всякие eventual consistency и мне так удобно воспринимать потоки данных. Как цепочки ивент - действия
SP
но я на всякий случай напомню - это имеет смысл там где "сложно" (там где гонки, там где бизнес логика часто меняется, там где нужны эксперементы). Тупой круд должен осаваться тупым крудом. Не надо тянуть сложные вещи в generic domain (лучше вообще взять from the shelf софт готовый). Всякие профили юзеров, регистрации и прочее в 99% ситуаций это тупо insert/update/etc и лучше юзать доступные инструменты (uniq constraint например или key value или еще чего - форсить на уровне стораджа)
A
Понял. Спасибо. Вообще мне в голову не приходит кейс, где уникальность логина нельзя проверить в рамках транзакции даже без средств бд
AI
А как ты без бд это проверишь ?
AI
Или ты наоборот о том, что без бд нельзя проверить ?