Domain driven design 当投注严重依赖账户余额时，如何建模投注/会计边界上下文？

假设您有一个应用程序，您可以在该应用程序中创建投币赌注。您的帐户有一笔用信用卡支付的余额

事件顺序如下：

邮政/投币投注{金额：5美元}

在Bet子域用例中启动事务/获取锁

用户是否有足够的余额？（检查用户存款的会计合计余额预测）

从用户帐户中借记5美元的金额

创建下注/抛硬币以获得结果

如果用户在正确的方向下注，则向其付款

提交事务

UI层被赋予下注并显示动画

我的问题是如何用两个独立的BoundedContext（博彩/会计）对此进行建模。它说，数据库事务不应该跨越边界上下文，因为它们可以位于不同的机器/微服务上，但在这种情况下，创建赌注的用例严重依赖于对用户预计帐户余额的非脏读取（强一致性）

由于UI层要求以原子方式创建赌注，因此，如果帐户的利息过高，也无法执行补偿操作

---

对于CQRS/事件来源，是否有任何方法不需要询问投注子域内的用户帐户余额？或者您是否必须始终确保此交易中的余额预测是正确的（它们必须一起部署）？

在您的情况下，确保帐户有足够的余额进行交易似乎是一个不变的业务规则。因此，让我们假设它不能被违反

那么问题就简单地说，如何处理跨越边界上下文的“事务”

DDD确实指出事务（不变边界）不应该跨越有界上下文（BC）。该规则甚至适用于骨料水平。但正确的读取方式是将事务作为“单个请求”的一部分

处理这种情况的最佳方法是简单地接受来自UI的下注请求，并返回“202 Accepted”状态消息以及唯一的作业跟踪器ID。请求处理过程中的唯一数据库交互应该是将数据持久化到“Jobs”表中，并可能触发“下注”域事件

然后，您将异步处理下注。是的，处理仍然需要调用Accounts绑定上下文，但需要通过其发布的API。由于您不再处于请求的上下文中，因此处理时间不需要符合通常的约束

处理完成后，UI将定期刷新页面并更新用户，或者您可以向浏览器发送推送通知