SP
где агрегат для одного этапа жизненного цикла пораждает агрегат для слещующего и т.д.
А по мне статус это просто условная метка позиции в каком либо воркфлоу.
Иметь понимание где мы по воркфлоу можно не имея поля status ни в сущности ни в базе
Size: a a a
2021 September 08
SP
бизнес процесс описывается явно, легко разбираться...
SP
статус классический нужен больше для UI
SP
а так всегда можно проверку статуса заменить на проверку "а есть у нас такой агрегат или еще нет"
КГ
Тут вроде обсуждают как user::setStatus дёргать, не похоже на ui)
SP
ну я к тому что вот этот status как "метка в воркфлоу" нужна больше пользователю, а в реальности этот "этап воркфлоу" можно по другому делать
SP
например - вот у тебя есть юзер и он в статусе "ждет подтверждения инвайта" - вместо статуса мы можем сделать отедльную сущность инвайт и тогда статус юзеру не нужен. Есть инвайт - значит он ждет подтверждения и т.д.
SP
желание логику изменения стэйта завязать на статусы - это одна из нескольких причин появления god objects в системе
SP
а потом сидишь в миро и рисуешь такой как у тебя статусы меняться могут и на что влияют.
SP
у меня перед глазами есть сущность - у нее чет типа 9 статусов или 10... и эту сущность можно разбить на 6-7 агрегатов и логика вся упростится
✨
ой мамочка... Давайте каждый тип в отдельные агрегаты переносить
SP
короч мой поинт в том что если статусов больше двух - надо быть оч осторожными с веедением такой вещи. а то реально потом будете обмазываться if-ами и никакие VO не спасут
SP
достаточно разобраться что такое агрегат и это перестанет казаться странной мыслью)
АС
Вот только надо ещё отметить что статусы, типы и прч. в базе в string хранить не надо, на крайняк enum, если есть
✨
да читала я Вернона
SP
миграции на них весело писать да
SP
все читали мало кто понимает
SP
если что - тебе стоит раскрыть мысль почему не надо. шоб индексы не пухли?)
✨
ну знач я длондинка ((