Как смоделировать ставки / учет BoundedContexts, когда ставки сильно зависят от баланса счета? - PullRequest
Новая
       105

Как смоделировать ставки / учет BoundedContexts, когда ставки сильно зависят от баланса счета?

0 голосов
/ 11 января 2020

Допустим, у вас есть приложение, в котором вы можете создать ставку на бросок монеты. На вашем счете есть баланс, который был пополнен с помощью вашей кредитной карты.

Последовательность событий следующая:

  1. POST / coin_toss_bets {сумма: 5 долларов США }

  2. Запустить транзакцию / получить блокировки внутри субдомена Bet useCase

  3. Достаточно ли у пользователя баланса? (проверьте прогноз совокупного баланса учета депозитов пользователей)

  4. Дебет счета пользователя на сумму 5 USD

  5. Создание ставки / флип монета для получения результата

  6. Выплата пользователю, если он поставил на правильную сторону

  7. Совершить транзакцию

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

Мой вопрос заключается в том, как это можно смоделировать с помощью 2 отдельных BoundedContexts (пари / учет). В нем говорится, что транзакции базы данных не должны пересекать BoundedContext, поскольку они могут быть расположены на разных машинах / микросервисах, но в этом сценарии сценарий использования при создании ставки в значительной степени зависит от незапятнанного считывания прогнозируемого баланса счета пользователя (строгая согласованность ).

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

Есть ли способ сделать это с CQRS / Event Sourcing, который не требует запроса баланса учетной записи пользователя в поддомене ставок? Или вам всегда нужно убедиться, что проекция баланса правильна внутри этой транзакции (они должны быть развернуты вместе)?

1 Ответ

0 голосов
/ 12 января 2020

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

Тогда вопрос заключается просто в том, как обрабатывать «транзакции», которые охватывают граничные контексты.

DDD действительно говорит, что транзакции (инвариантные границы ) не должен пересекать ограниченный контекст (B C). Правило применимо даже на уровне агрегатов. Но правильным способом его чтения будет транзакция как часть «одного запроса».

Лучший способ справиться с этим сценарием - просто принять запрос от пользовательского интерфейса, чтобы сделать ставку, и вернуть «202». Принят »сообщение о состоянии, вместе с уникальным идентификатором отслеживания работы. Единственное взаимодействие с базой данных во время обработки запроса должно состоять в том, чтобы сохранить данные в таблице «Задания» и, вероятно, вызвать событие домена «BET_PLACED».

После этого вы будете обрабатывать ставку асинхронно. Да, обработка все равно будет включать вызов ограниченного контекста Аккаунтов, но через опубликованный API. Поскольку вы больше не находитесь в контексте запроса, время обработки не обязательно укладывается в обычные ограничения.

После завершения обработки любой пользовательский интерфейс будет регулярно обновлять sh страницу и обновлять Пользователь, или вы можете отправить Pu sh Уведомление в браузер.

...