为什么聚合中的每个数据更改都应该在事务中进行？

Question

给定一个订单聚合，它由Order和OrderItems组成。Order是聚合根。下单是唯一需要事务来保证数据一致性的场景。或者至少有很多场景涉及按顺序和orderItems更改不需要事务的数据。

在DDD之前，事务是在创建方法时做出的决策。您通常会考虑此方法或行为是否需要在事务中才能保持一致性。

DDD建议为聚合root公开的每个可能的行为创建一个事务。这实际上会导致更多的死锁。

我认为我不必在事务中实现聚合根中的每个数据更改行为。

例如，如果您只更改发货详细信息，为什么需要事务处理。如果您只删除一个订单项，为什么需要一个事务。因此，对于Order.UpdateOrder和Order.DeleteOrderItem方法，我们不应该考虑事务。

我错过了什么吗？

Answer 1

是的，我想你错过了一些东西。如果您正确地设计了聚合，尤其是如果您将它们设计得足够小，那么您将不会有无意义的事务，至少不会有很多事务。您的聚合应该是高度内聚的，因此并发修改的属性/状态应该留在相同的聚合中；这就是聚合的要点，以保护对状态的并发访问。

如果您的聚合比它们应该的大，那么有一个很大的变化，聚合force-field太宽，没有内聚性的命令将被无用地序列化。

关于orders，不会有很多失败的事务，因为同时添加order item和更改order shipping details的概率非常低。

Answer 2

在最纯粹的形式中，您的存储库只有很少的方法：

public interface IAggregateRepository
{
    AggregateRoot Get(Guid id);
    void Save(AggregateRoot instance);
}

在此场景中，用例/命令之间没有区别。您不一定知道是否需要事务。

另一个考虑事项是，事务应该在集成/应用程序层中处理。这使得事务处理更远离领域交互。

您可以让应用程序了解特定的用例，并决定放弃某些命令的事务。然而，这可能是更多的努力，这是值得的。

最后一点是，事务不仅与您正在做的事情有关，还与其他人正在做的事情有关。

为了谨慎起见，我更倾向于使用事务。如果有特定的原因不使用事务，那么这当然是一个选择，但这似乎更适合于读取。

Answer 3

如果您只需要在系统中的某处更新发货详细信息，而不是遵循核心DDD方法，那么您可能具有具有不同聚合的不同绑定上下文，让我们将其称为ShippingRequest，它只有两个字段：OrderId和ShippingDetails，并且最终可能映射到相同的底层表，也可能不映射到同一个基础表。然后，这个聚合被事务隐式地覆盖，因为它只映射到一个表。

或者，您可能不想关心所有这些有界上下文、无处不在的语言和聚合，因为DDD不值得实现，而一些传统的CRUD/事务脚本方法就足够了。

另一个问题是，DDD通常是在错误的例子上解释的。聚合定义了一些一致性边界，一些代表您的业务规则的不变量。因此，在Order作为聚合的情况下，假设order被分配了一个最大允许总数，该值不能超过。然后成为一个自然聚合，因为每当您想要添加或删除一个项目时，整个聚合都必须作为单个原子单元进行检索和更新。