Но один юзер л других знать ничего не должен и для проверки у тебя нет зависимостей от данных юзера (ты мол ещё не поменял ничего) из-за чего имело бы смысл рассматривать вариант с прокалыванием зависимостей в юзера

на уровне бд проще всего

если при сохранении получаешь ошибку из бдшки, типа unique constraint violation, посылаешь 400ый код на фронт с описанием ошибки и просишь ввести новый логин

Хорошо, а если такая проверка в базе невозможна, но все ещё нужно проверять какие то свойства у всех юзеров?

Вопрос того насколько у тебя требования к атомарности операции. Например может быть так что выгодно сначала записать а потом искать дубли и если они есть - переходить в какой-то альтернативный флоу.

С теми же именами пользователя - есть конфликт - добавили суффикс - нет конфликта

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

Просто до подтверждения отсутствия дублей можно ещё операции чуть разделить.

Есть наркоманы которые делают семафоры всякие на рэдисах но это обычно кучу проблем влечет

А если нельзя самому разрулить, как в случае с пользователем? Допустим, заплатил деньги за переименование и получил не то что хотел. Или кейс когда модификация  невалидных данных на правильные нетривиальная/сложная операция

Тогда проверить перед операцией https://github.com/deworkerpro/demo-auction/blob/master/api/src/Auth/Command/ChangeEmail/Request/Handler.php#L41

Но, как сказали выше про конкурентность, если не сделать кнопку в UI неактивной сразу после нажатия, то при двойном клике проверка не сработает и всё равно вылетит ошибка unique из БД.

юзеры могут покупать предметы у системы. т.е. у User.buy(item) снимает средства и записывает в бд что item теперь user'a.
теперь бизнес захотел чтобы юзеры могли выставлять на продажу свои предметы и покупать у других.
чтобы не перемешивать логику купли\продажи между юзерами в User я хочу сделать класс Trader в котором и будут buy(),sell(),withdrawFromSell() и прочие.
есть ли смысл совместить логику покупки у системы (тип продавца SYSTEM) и как лучше сделать это?

это вроде похоже bounded context

> есть ли смысл совместить логику покупки у системы (тип продавца SYSTEM) и как лучше сделать это?

слишком мало известно что бы предлагать такие решения. По дефолту лучше все воспринимать как разные вещи и склеивать когда ты получишь достаточно подтверждений что это все одно и то же. Для этого нужно немного разбираться в том кто откуда и зачем хочет требования менять. Кто пользуется и т.д. Часто очень похожая логика в будущем будет сильно меняться и подобные обобщения будут замедлять разработку.

навскидку я придумал несколько кейсов которые возникнут в будущем которые упростили бы разработку с такой моделью, но добавляют сложность на текущем этапе. переделать не слишком дорого, но добавляются варианты использования в application

я в целом еще рекомендовал бы не делать user.buy или уточнять что кроме buy у этого "user" больше методов нет и операций. Ну то есть... вот это проектирование через сущности может выйти боком. Возможно лучше по дефолту идти по стратегии юзкейсов (Purchase класс какой с одним методом).

часто видел как люди пытались в общие сущности вроде юзера того же класть слишком много, в итоге на выходе god object и много accedental coupling

(да и сам так делал, нахлебался)

Вообще чаще всего в user нужен только userId
Остальное это отдельные штуки связанные с userId
Типа authEmail, authPhone, authFacebook и тд

Спасибо. Книга отличная.
Я вообще читал её полностью и где-то половинку Гради Буча.
После Вайсфельда не хватило знаний\сил GoF осилить. Сейчас после Буча и вики уже не уверен, но все равно такое ощущение, что как будто не понимаю, как надо. Я не глупенький в целом, так, наверное может показаться. Просто хочу именно хороший уровень понимания.
Сейчас отметил себе:
Metz, Sandi - Practical object-oriented design_ an agile primer using Ruby
И наверное потом head first design patterns

А тебе эти паттерны дают, что-то на практике?
Я вот просто ничего из этого не читал,  даже gof. Разве что гуглил некоторые паттерны