domain-driven-design - 在 DDD 中，每个存储库或限界上下文或事务的 UoW？

Question

在 DDD 中，聚合根可以有一个存储库。让我们拿一个 订购 聚合和它的非持久对应 订单库 和持久的对应 下单 .我们还有 ProductVariant 跟踪订单中产品库存的聚合。它可以有一个 ProductVariantRepository 和 ProductVariantUoW .

Order 和 ProductVariant 的工作方式是在持久化订单之前检查库存。如果有库存，将通过调用 OrderUoW.Commit() 来持久化订单。是的，接下来将调用 ProductVariantUoW.Commit() 来更新产品的库存。

不幸的是，事情可能会变糟，用户在短时间内购买了相同的产品(将此视为两个用户购买相同产品的网络应用程序)。现在第二个用户的整个交易应该通过恢复刚刚创建的订单而失败。我应该调用 OrderUoW 来回滚更改(应该从数据库中删除订单)？或者我应该将两个 UoW.Commit() 操作都放在一个事务范围内，因此一个 commit() 失败将回滚更改？或者两个存储库(Order、ProductVariant)都应该只有 UoW 并且它只需要有一个事务范围？

我可以通过说在涉及多个存储库的情况下如何处理事务来使故事简短？

Answer 1

我们可以问的一个问题是谁在做以下事情:

The way the Order and the ProductVariant work is that before the order is persisted, the inventory is checked. If there is inventory, the order will be persisted by calling OrderUoW.Commit(). Yes, the ProductVariantUoW.Commit() will be called next to update the inventory of the products.

有人认为这种工作属于服务层，它允许服务层将跨越聚合对象的事物放入单个事务中。

根据 http://www.infoq.com/articles/ddd-in-practice :

Some developers prefer managing the transactions in the DAO classes which is a poor design. This results in too fine-grained transaction control which doesn't give the flexibility of managing the use cases where the transactions span multiple domain objects. Service classes should handle transactions; this way even if the transaction spans multiple domain objects, the service class can manage the transaction since in most of the use cases the Service class handles the control flow.

我认为作为使用单个事务的替代方法，您可以使用 ProductVariant 声明库存，如果所有必要的库存项目都可用，那么您可以提交订单。否则(即您无法领取订单所需的所有产品)，您必须退回使用补偿交易成功领取的库存。结果是在一个订单提交不成功的情况下，一些库存会暂时出现其他订单不可用，但好处是你可以在没有分布式事务的情况下工作。

尽管如此，这个逻辑仍然属于服务层，而不是 DAO 类。