domain-driven-design - DDD : creating multiple aggregates with a shared life-cycle in a single transaction

Question

据我所知，我知道每个事务只应修改一个聚合的一般规则，主要用于并发和事务一致性问题。
我有一个用例，我想在单个事务中创建多个聚合:RestaurantManager , Restaurant , 和 Menu .它们看起来像一个聚合体，因为它们的生命周期开始和结束在一起:在域内创建 RestaurantManager 没有意义。没有 Restaurant ， 或相反亦然; Restaurant 也是如此和一个 Menu .此外，如果 Restaurant或 RestaurantManager被删除(未注册)，它们应该一起删除。
但是，我将它们拆分为单独的聚合，因为一旦创建，它们将单独更新，维护自己的不变量，而且我不想将它们全部加载到内存中只是为了更新 Restaurant 上的一个属性。 ， 例如。
唯一将它们联系在一起的是它们的生命周期。
我的问题是，这是否代表可以违反每个事务只能在单个聚合上运行的“规则”的情况。
我还想知道是否应该通过让每个聚合根持有它所依赖的聚合根的标识符来在域模型中强制执行它们的共享生命周期，即通过 Restaurant需要 MenuId作为构造函数参数，同样用于 Menu和 RestaurantId ，所以没有另一个就不能创建。然而，这仍然不会强制应用程序服务将它们保存在一起，因为它可以在内存中创建它们，然后只保存 Menu ， 例如。

Answer 1

您的要求是 DDD 中的一个非常正常的用例，恕我直言。总是有多个聚合体协同工作来支持应用程序，并且它们的生命周期是相互关联的。但建模概念仍然适用。让我尝试在一些 DDD 规则的帮助下解释您的模型的外观:
聚合是事务边界
聚合确保在任何时候都不会破坏业务不变量。这意味着，如果您将多个聚合串在一起作为一个事务的一部分，则必须将它们全部加载到内存中以进行验证。
当您的应用程序数据丰富并将数据存储在数据库集群中时，这尤其是一个问题 - 分区的、分布式的(想想 Mongo 或 Elasticsearch)。您将面临从潜在不同集群加载数据作为单个事务的一部分的问题。
聚合被完整加载
聚合及其关联的数据对象被整体加载到内存中。这意味着交易的不必要对象(例如餐厅下个月的时间表)可能会加载到内存中。就其本身而言，这不是问题。但是当多个聚合聚集在一起时，需要考虑加载到内存中的数据量。
聚合通过其唯一标识符相互引用
这个很简单，意味着每个聚合都通过它们的标识符存储其引用的聚合，而不是将另一个聚合的数据封装在其中。
跨聚合的状态更改通过领域事件处理
如果您希望一个聚合中的状态更改对其他聚合产生副作用，您可以发布域事件，并且订阅者在后台处理其他聚合上的更改。这就是您想要处理级联删除要求的方式。

通过遵循这些规则，您实际上是一次放大一个聚合并确保复杂性保持在较低水平。当您将多个聚合串联起来时，尽管在第一天就清晰易懂，但最终，应用程序往往会变成一个大泥球，因为依赖项和不变量开始相互交叉。