Size: a a a

Software Design/Architecture/Zen

2021 July 28

ПГ

Павел Г. in Software Design/Architecture/Zen
Делаем, но еще есть дубль на бэке
источник

ПГ

Павел Г. in Software Design/Architecture/Zen
Ну это вариант решения.
источник

ПГ

Павел Г. in Software Design/Architecture/Zen
Хотя опять таки - это изменение требований
источник

HH

Human Human in Software Design/Architecture/Zen
Хм, сомнительное утеверждение. У тебя агрегаты и вот это вот все выстраивается в зависимости от твоих юзкейсов
источник

ПГ

Павел Г. in Software Design/Architecture/Zen
При этом ui может быть совершенно разный. Я могу сделать 1 форму на 100 полей, или 10 форм с разными стадиями по 10 полей. Но в рамках бизнес процессов - особо ничего не поменяется.
источник

HH

Human Human in Software Design/Architecture/Zen
Так делай заранее подтверждение адреса на беке. Чтобы когда подтверждалось - адрес уже был верен
источник

ПГ

Павел Г. in Software Design/Architecture/Zen
Так проверка после изменения статуса заказа :) А у заказа тоже есть свои проверки
источник

HH

Human Human in Software Design/Architecture/Zen
Не понятно почему именно после изменения статуса заказа, ты же не поясняешь.
источник

AK

Aleh Kashnikau in Software Design/Architecture/Zen
это не совсем так, task based ui как раз позволит легче бить на агрегаты и ивенты и адекватнее показывать ошибку, одна большая форма всегда будет навязывать решение ближе к crud. Если crud подходит, т.е. нет особой конкуренции за ресурсы и можно вот все залочить и подождать, то зачем усложнять решение
источник

AK

Aleh Kashnikau in Software Design/Architecture/Zen
один большой “агрегат”, так один большой “агрегат”
источник

ПГ

Павел Г. in Software Design/Architecture/Zen
Можно поменять местами, но у заказа есть свои проверки.
источник

HH

Human Human in Software Design/Architecture/Zen
Тогда мб это один агрегат, либо делай распределенные транзакции
источник

HH

Human Human in Software Design/Architecture/Zen
Ну вот при подтверждении заказа у тебя уже будет там подтвержденный адрес, останется только проверки твои сделать. При чем здесь “доставка”. И что это вообще за доставка. Возможно ты просто логически разедлил, а не по юзкейсам
источник

k

knopkod4v in Software Design/Architecture/Zen
Как там Уди про требования говорил "Бизнес не приходит с требованиями, бизнес приходит с воркэраундами".
источник

k

knopkod4v in Software Design/Architecture/Zen
и вот ещё вспомнилось
источник

NF

Nikita Fedorov in Software Design/Architecture/Zen
ну а где статус "оформлен"?) пока что ты назвал 2 стауса и ни один из них не указан в требованиях)
источник

NF

Nikita Fedorov in Software Design/Architecture/Zen
🙃
источник

HH

Human Human in Software Design/Architecture/Zen
@dexplon Агрегаты это больше похожи на юзкейсы, чем на логические сущности
источник

ПГ

Павел Г. in Software Design/Architecture/Zen
Есть два юзкейса:
1) Подтверждение заказа. Проверка баланса пользователя. Изменение статуса заказа. Над этим агрегатом работает отдел производства.
2) Сохранение доставки. Проверка адреса по апи. Сохранение агрегата/сущности, круда хз как верно тут будет. Над которым потом будет работать отдел доставки .
Я сейчас оборачиваю для простоты это все в транзакцию над уровнем юзкейса. Все работает все ок. Хочу понять как делается верно.
источник

ПГ

Павел Г. in Software Design/Architecture/Zen
Статус создан, статус подтвержден (оформлен). Возможно последний статус по разному называл в рамках текущей беседы
источник