ЕР
Никто не помешает )
Вот именно
Size: a a a
2020 May 13
M
Вот именно
Так же никто не помешает воспользоваться рефлексией
ЕР
Так же никто не помешает воспользоваться рефлексией
Отсутствие в команде людей делающих такую фигню помешает
ЕР
А в твоём кейсе вся работа строится на том что сущность меняет кто захочет
M
Отсутствие в команде людей делающих такую фигню помешает
Отсутствие в команде людей, сохраняющих невалижные сущности, тоже помешает
ЕР
Отсутствие в команде людей, сохраняющих невалижные сущности, тоже помешает
Нет
ЕР
Способ определить валидна сущность или нет в твоём кейсе - это держать в голове всю логику всех сервисов работающих с сущностью
ЕР
Чем их больше тем больше будет багов
M
Так ты же привел кейс когда у тебя множество действий над одной сущностью, если поля разные, то почему сущность одна?
Например, заказ может хранить доставку, оплату, скидки. Это разные операции, связанные с одним заказом.
M
Способ определить валидна сущность или нет в твоём кейсе - это держать в голове всю логику всех сервисов работающих с сущностью
Сущность ты сохраняешь один раз, вот в одном месте и нужно сделать проверку
ЕР
Сущность ты сохраняешь один раз, вот в одном месте и нужно сделать проверку
Вот есть у тебя правило, что заказ не может из статуса "delivered" перейти в статус "shipping", как ты это на валидации проверишь?
M
Вот есть у тебя правило, что заказ не может из статуса "delivered" перейти в статус "shipping", как ты это на валидации проверишь?
В методе смены статуса
ЕР
В методе смены статуса
То есть в сервисе?
M
То есть в сервисе?
Да
ЕР
Это будет отдельный сервис смены статуса?
M
Это будет отдельный сервис смены статуса?
Да хоть так. Зависит от ситуации.
M
Может у тебя там целая система по смене статусов )
ЕР
И сразу +1 зависимость в сервис доставки, в сервис создания заказа и т.п.
ЕР
Что если для установки статуса shipped, нужно заполненное поле вроде "адрес" или "служба доставки"?
ЕР
Сервис смены статусов начнет работать и с этими полями?