Приветствую :) вопросик по транзакциям и агрегатам опять :) Простой

кейс: перевод денег с одного счета на другой. Две insert операции в базу. По идее 2 агрегата счетов двух пользователей. Как правильно поддержать консистентность в этом кейсе? Простое решение - все завернуть в одну транзакцию. Но ведь тут два агрегата, значит должно быть две отдельных транзакции. Делать конпенсационные действия в случае ошибки или делать какой то виртуальный агрегат "Счета", где как раз и будут такие операции проходить в одной транзакции и работа с счетами как с коллекциями (звучит бредово)?

Ну тут да :) я про самый простой вараинт, чисто в рамках монолита без внешний систем.

Транзакция и баста. Если хочется усложнять жизнь - сделать подсчёт балансов на основе переводов в первую очередь :) Тут же на самом деле первоочередной перевод, он же дифф, а баланс как поле юзера - просто некоторый «снэпшот». Но основной источник правды - переводы.

Ну а как же 1 агрегат = 1 транзакция?... Или типо можно подзабить когда очень хочется? :)

https://ru.wikipedia.org/wiki/%D0%94%D0%B2%D0%BE%D0%B9%D0%BD%D0%B0%D1%8F_%D0%B7%D0%B0%D0%BF%D0%B8%D1%81%D1%8C

Спасибо 👍 почитаю

Агрегат же может быть пачкой сущностей, а тут по идее нам нужно именно что два счета атомарно изменить. И в терминах той же двойной записи (что скинули выше) - в одной транзакции может быть создано множество проводок, и заодно обновлено множество «снэпшотов» балансов.

для меня основное что они как раз независимо могут создаватся без необходимости транзакций и локов Ф двойная запись служит проверочным кодом котрый позволяет увидеть ошибку и устранить например руками или автоматически

Ну вот я такой вариант обдумывал, но смущает, что у этого агрегата нет идентификатора. Или это агрегат транзакция... Короче я не знаю, поэтому спрашиваю)

Это не усложнение жизни а облегчение как раз в итоге)

Это не совсем правда. Встречаются вполне себе бизнесово атомарное множество проводок. Можно тут конечно пытаться это неатомарно делать в БД, но пока от этого больше сложности и проблем, нежели бонусов. Ну и опять же, снэпшоты балансов подбивать можно асинхронно, а в моменте смотреть на снэпшот+проводки. Но тут уже больше зависит от конкретных нагрузок, и тонкого тюнинга.

Да не все используют SQL базы даных ВОт вам DynamoDb в руки и баста Не люблю юизнес логику завязывать на базу данных а не на код.

С мой точки зрения, тут есть перевод/платеж/транзакция, и в рамках него есть множество проводок(это если про двойную запись говорить).

> Вот вам DynamoDb в руки и баста А я люблю брать инструмент под задачу, а не задачу на инструмент натягивать 🙂 SQL отлично для финансов заходит, особенно там - где и хочется иметь все эти гарантии SQL.

Та я же не против как пример привел Это нормально перекладывать на бызу данных твественность ибо доверять современным разработчикам такое себе решение 😄

ну да ну да, овердрафты например

https://www.youtube.com/watch?v=gpam7RGPFk8&ab_channel=JOnTheBeach

Овердрафты же про знак баланса, и именно что уже "бизнесовые" требования/ситуации в реальном мире. В моем случае от БД мне нужны именно что транзакционность да FK по большому счету.

Спасибо, гляну, может чего открою для себя еще

двойная запись появилась за миллиард лет до ДДД, программирования и компьютеров, зачем придумывать велоспиед)

Подождите, двойная запись - это хорошо! Я лишь про то, что в ней иногда хочется сами записи добавлять атомарным батчем

а еще хочется быстро производить расчеты

Безусловно, но на пути расчета еще отрабатывает различный антифрод/ТМ, коммуникации вообще со внешними платежными сервисами, что занимает много больше времени, что атомарный инсерт в SQL DB, я не прав?

да, занимает, и если это затрагивает 0.1% пользователей то можно проектировать систему так что бы остальным 99.9% ждать не надо было

Вот в моем случае это занимает 100% пользователей, как и у какого-нибудь Mastercard по идее )