ПГ
Я просто хочу минусы понять.
Size: a a a
2021 July 28
AL
Это все должно быть скрыто на уровне "инфаструктуры"
AL
т.е. когда сага говорит "отменить", это по-факту можнт оказаться rollback в бд.
AK
а можете чуть подробнее описать когда происходит сохранение заказа с доставками? Это покупатель до оплаты делает или это он у себя в истории в профиле что-томеняет?
AL
а может быть и новый запрос с удалением, например.
ПГ
Хм, т.е. кейс не совсем плох...
AL
но как только этот роллбек будет влиять на что-то еще неявным образом -- это сразу no go.
ПГ
До оплаты. Пользователь оформляет конфигурацию заказа и доставки и все это скопом улетает на бэк.
HH
Минус большого агрегата в том, что тебе прийдется лочить все эти данные внутри агрегата. Те умньшаешь пропускную способность. Если тебе это не нужно, то фигачь атомарно в бд и не парься
ПГ
Так это не большой агргегат, а два поменьше и вопрос как лучше сохранять их атомарно
HH
Минус саг - это более сложно инфраструктурно. Я думаю за это нужно платить, если это нужно.
HH
Значит ты не понял понятие агрегат. Это и есть атомарная граница.
HH
Если ты хочешь что-то сохранять атомарно, это уже один агрегат. Либо переделывай границы
ПГ
Вот кейс: заказ и доставка. Два агрегата. Должны сохраниться или не сохраниться вместе (в конченом итоге).
ПГ
Это же не одни год агрегат
k
почему должны?
AK
если происходит в одной транзакции, то это один большой агрегат, то что по коду у вас есть какие-то псевдоагрегаты ничего не меняет. Агрегат это граница транзакции
ПГ
Ну а как - заказ подтведился, а потом проверка каких то данных при сохранении доставки - выдало ошибку. Мне надо или откатывать заказ или поддержать по другому откат на начальную стадию общей операции
HH
Ну тогда у тебя появляется асинхронность и итоговая согласнованность вместо атомарной. Это сложнее инфраструктурно поддерживать, но если тебе нужна масштабируемость и пропускная способность - делай
AK
конфигурация заказа это чего сколько хочет купить? + куда доставить