Пардон. Понял о чем вы

В том числе, но не только конечная.

Нужна согласованность в момент транзакции. без полного отката ее в случае проблемы. С преждевременным обнаружением и возможностью в ручную разрешить конфликт с обоснованной регистрацией изменения.

вопрос же только в требованиях к времени выполнения?
Ну то есть останавливать время же всё равно придётся

короче я тоже не понял
снепшот в рантайм, рантайм по аптайм 🤔

в одном случае вы диктуете остановку, в другом случае ее или нет в принципе или она не соответствует вашим циклам поставки и расчета (бизнеса). Примерно так, но опять таки, я про свои кейсы. может оно и не надо, и ваша диктовка остановки, даже избыточней (чаще и предвещает) циклов поставки и расчета бизнеса.

короче, ну его это ИТ... буду [вставить свое]

проблемы ли это. ну то есть.... то что стэйт системы может не быть консистентным в конкретный момент времени не есть проблема сама по себе.

мне очень нравится пример Альберто Брандолини из его книжки про event storming. мол у него там был пример на тему того что бизнес по своей природе строится на доверии и на eventual consistency.

идешь ты такой по парку и захотел покушать. Стоит лоток с хотдогами. Ты такой подходишь к нему и просишь мол "дай ка мне хотдог", а он такой "5 баксов". Ты даешь ему деньги и ждешь. И пока ты ждешь он вполне может сбежать с твоими 5-ю баксами и не будет хотдога.

И в целом операцию обмена такую никак не выйдет сделать атомарно. Невозможно за одну операцию сьесть хотдог и обменяться деньгами.

в целом в подавляющем большинстве случаев у твоих бизнес операций есть причинно следственные связи которые позволяют тебе проще управлять этим самым eventual consistency. но да - часто выгоднее построить систему детекта конфликтов и возможность вручную решения принимать - это будет возникать в 1% ситуаций и обычно там большая часть сложности при обработке транзакций которую можно переложить на человека

модерация обычная

у бизнеса есть люди,которые занмаются этим.

обычная которую надо закладывать в дизайн системы

люди часто любят усложнять и тип "система должна сама решать"

оч крутые примеры "сложных" кейсов были у Грега Янга - там он рассматривал систему обработчи чеков где есть целая куча нюансов аля "чек действителен с такой-то даты" или "на счет был наложен невидимый холд федеральным бюро расследований и хз че в этой ситуации делать".

да, вопрос в том что конфликт может моделироваться при эскалации, но для этого он должен "отслеживаться" и должен иметь критерии модерации. и тут мы ловим стандартные проблемы

усложнил.

но можно прописать концепт в котором мы можем доверять потребителю, а не просто его заявлении о получении не получении, потреблении не потреблении. кстати именно это пытались продать в блокчейне, но потом оказалось что не всем это нужно, и доверие не совсем полное.

ну все эти "стандартные проблемы" возникают там где мы уже решили что полностью откатывать операции нельзя. Условно у нас уже эти проблемы есть, как мы с ними сражаемся и детектим это уже детали и есть варианты.

ну мол.... обойти это не выйдет в целом так что не очень понятно даже о чем рассуждение идет. Если у нас есть нефункциональные требования которые все это подразумевают то "щито делать"

Добрый вечер.
Какую структуру проекта можете порекомендовать ?
Слышал, что domain infra app выглядят смешно.

Для себя выработал:
проект по названию сервиса
app
host

Feature based