Например ID и дата появления в системе, которые потом дополняются контактной информацией при регистрации
а откуда берется ID? как это работает?
Например, когда юзер добавляет товар в корзину, в системе регистрируется анонимный пользователь и создаётся анонимная сессия (да, корзину можно сделать на клиенте, но можно привести и другие примеры)
А далее при регистрации (или других действиях) его данные дополняются, но это если вообще не делить их на уровне архитектуры
Например, при оформлении заказа может появиться контактная информация, но не пароль
то есть у нас грубо в сессии может лежать юзер без всего, юзер с паролем и юзер с профилем, и для этих сущностей будут разные юзекейсы? и надо в хендлере каком-то красиво вызывать нужный?
Да, юзкейсы иногда будут немного отличаться, и это проблема, если лепить в системе "одного" пользователя
слушай, а вы серьезно под каждый usecase создаете отдельный тип? type SigninUseCase ... type AddProductUseCase ... так, да?
тяжко вам)
наоборот, очень удобно. они еще могут друг друга вызывать:)
чур, чур. а не пробовали AuthUseCase и все юзкейсы методами оформлять?)
ну это то, с чего я интуитивно начал, но тут возникает проблема - такой класс расширяется, тесты к нему становятся жирными, потом не поймешь, сколько методов из него нужно твоей зависимости. У меня в репозиториях и в транспортах может быть много методов
user_usecase.go user_usecase_auth.go user_usecase_order.go
Мы тоже🤝
Обсуждают сегодня