Transactions 实现领域驱动的设计手册

我目前正在阅读《实现领域驱动设计》一书，其中一页显示

public class ProductBacklogItemService ... {
    ...
    @Transactional
    public void planProductBacklogItem(
        String aTenantId, String aProductId,
        String aSummary, String aCategory,
        String aBacklogItemType, String aStoryPoints) {

        Product product =
            productRepository.productOfId(
                    new TenantId(aTenantId),
                    new ProductId(aProductId));

        BacklogItem plannedBacklogItem =
            product.planBacklogItem(
                    aSummary,
                    aCategory,
                    BacklogItemType.valueOf(aBacklogItemType),
                    StoryPoints.valueOf(aStoryPoints));

        backlogItemRepository.add(plannedBacklogItem);
    }
    ...
}

他的书还提到参考：在DDD中，聚合应该代表事务边界。一个需要多个聚合参与的事务通常是一个迹象，表明要么应该细化模型，要么应该审查事务需求，要么两者兼而有之

---

在上面的例子中，Product和BacklogItem在一个事务中不是两个不同的聚合吗？我很困惑。有人能分享一些想法吗？

我认为在这种情况下，“参与”可能意味着“更改”，并且由于

产品

没有修改，因此只有一个AR受到影响。事实上，我昨晚读了这篇文章，更进一步，他确实提到了一个真正的目标应该是每笔交易只操纵一个AR。因此，似乎会有例外

每个事务只操作一个AR并不是一个坏主意，通常您会发现最终还是会得到这样的设计

---

这条规则总会有例外，但必须仔细考虑。

我认为产品包含一个backlogitem集合，因此两个AR都会受到影响，产品和backlogitem。不过，这不是一个教条，而是一个指南。创建聚合时，通常由另一个聚合执行。如果我没记错的话，这就是最初的“大”AR被分成不同AR的地方。因此，最初

产品

包含集合，但它们不应再位于

产品

上，因为存储库现在表示该集合。

产品现在只包含工厂方法，可能是为了正确创建关联。以下是Udi Dahan的一篇文章，大意与此相同：