Здравствуйте, gandjustas, Вы писали:

G>·>Ты упускаешь мою мысль, что этот код — не особенность МСА-реализации, а реальность бизнес-задачи.
G>Что означает "реальность бизнес-задачи" ?
G>Каким образом бизнес-задача приводит к нас к нескольким базам?
Реальные физические акторы физически разделены и физически невозможно обеспечить 100% надёжную коммуникацию между ними. Поэтому в CAP будет присутствовать компонента P, хочется тебе того или нет.

G>·>Просто в твоём монолитном решении ты игнорируешь эту проблему.
G>О какой проблеме идет речь?
"задачу, которая откатывает незавершенные резервы".

G>·>1. Пользователь создаёт заказ
G>·>2. Склад резервирует заказ
G>·>3. Пользователь завершает заказ
G>И что? Нам поэтому нужно сделать отдельные базы для Заказа, Склада и Пользователя, чтобы соответствовало существительным?
Не чтобы соответствовало существительным, а чтобы сабж.

G>А как в 1С конфигурации УНФ это все в одной базе существует? Оно как-то неправильно работает?
G>В 1С вообще это все решалось в рамках одной базы задолго до появления термина "микросервисы". В чем они неправы?
Хреново 1С работает. Не знаю как оно изменилось с тех пор, но раньше это был просто ад — все ломятся через RDP на один гигасервер и простейшие операции работают минуты. И если что-то где-то упало, то всё и сразу лежит.

G>·>И вот когда ты опишешь задачу так, то совершенно ВНЕЗАПНО получается, что "надо написать еще фоновую задачу, которая откатывает незавершенные резервы" в любом случае, неважно — МСА у тебя или монолит.
G>Важно. В монолите это все не нужно. Монобаза тебе обеспечивает атомарность, вообще всегда.
Если после 2-го пункта произойдёт какая-либо ошибка, как тебе поможет твоя атомаронсть?