то чувство когда подходишь к книге 3 раз за 3 года, а мозгов не хватает))

Соглашусь с Егором. Оно того вообще не стоит.

Объектно-ориентированное мышление - Вайсфельд Мэтт
в свое время отметил ее для себя, может зайдет

Люди не первый раз на gof наступают)

нит, нинада. лучше мобикс

Не, не лучше

эффектор точно не лучше :)

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

мобикс щас наименее бойлерплейтный и болезненный, а с функциональными сторами-фабриками вообще красиво стало

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

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

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

Транзакция и баста.

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

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

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

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

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

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

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

Историчность в денежных переводах должна сохраняться, так что тут это даже на бизнес ложится идеально