Domain driven design 我应该如何处理多个聚合根交互

我读过这篇文章，在这篇文章中，Udi Dahan谈到了多对多的关系。 在这个例子中，他解释说，在多对多关系的情况下，比如一个作业与作业板之间的关系，并且考虑到向作业板添加作业的有界上下文，聚合根将是作业板，您只需将作业添加到其中。 在评论部分，他还解释了在不同的有界上下文中，作业将是聚合根，这是有意义的，因为作业可以在没有作业板的情况下存在，并且可以对作业执行许多操作，这些操作不会影响作业板。 我有一个类似的问题，但我似乎不知道这将如何解决。我有两个问题：

如果我们需要删除一个作业，看起来取决于该作业是否已发布，我们将需要单独删除作业，或者删除作业，但同时将其从板上删除，这意味着修改同一事务中的两个聚合根，但该代码应该放在何处？域名服务

若job和job board可以是两个不同的聚合，那个么job实体需要同时存在于这两个上下文中，那个么我们如何处理这个问题，只需创建两个包含重复数据的job类

更新1：

这就是我正在处理的情况。。。我有一个路由应用程序，我有代表旅行请求的请求，我有路线，有站点，每个站点有一个或多个请求。为了创建路由，我使用一个执行路由的外部服务，并将路由结果存储在路由表中

问题是，我不知道如何建模这种关系，这里有一个用例来考虑，请求取消是一个依赖于请求的状态和路由的状态会导致不同动作的过程：

请求未被路由（未分配到路由），只需取消请求即可

请求被路由，路由被调度，然后取消请求，从路由中删除请求，并重新创建路由（使用外部库），因为删除请求可能导致删除站点，所以我需要重新创建路由内部，这仍然是一个更新

请求已路由，路由正在路由中，然后我将请求标记为不显示，并更新路由

因此，起初我认为请求、路由和路由表是单独的聚合，但这意味着我需要在同一事务中修改多个聚合（通过使用服务或使用域事件） 我不确定创建一个更高级别的聚合根目录（包含请求、路由数据以及最终的路由数据）是否有意义，因为我并不总是拥有加载聚合根目录的所有数据，事实上大多数情况下，我都会有一部分聚合根目录，无论是一个请求还是一个包含多个请求的路由。 我愿意接受建议，因为我似乎找不到解决这个问题的办法

更新2： 因此，添加更多上下文，我将为实体添加更多细节：

• 请求，它表示一个行程请求，它具有多个状态和一个已定义的工作流
• 路由，它有一个定义的工作流和定义的转换，有一个站点集合，每个站点有一个有效负载集合，每个有效负载有一个请求id，（路由->站点[]->有效负载[]->请求id）
• 路由，它表示调用路由引擎的结果，该引擎基于您想要路由的一系列请求，它将生成路由

因此，这些实体存储在mongodb集合中，让我们看看用例：

UC-请求取消 我可以仅使用请求id取消请求，但根据请求的状态，我可能还需要修改路由。 1个请求没有路由，所以使用请求id，我得到请求并取消它，这一个很简单。 2请求被路由，路由被调度，在这种情况下，我需要获取请求，然后获取路由和绑定到该路由的所有请求（包括触发命令的请求），然后移除绑定到请求的有效负载（以及停止，如果它只有一个有效负载），由于此选项可以更改站点，我需要使用外部api（路由引擎）重新创建路由，并在路由表中创建一个条目。 3请求已路由，且路由正在路由中，在这种情况下，我需要获取请求，然后获取路由和与该路由相关的所有请求（包括触发命令的请求），并将请求更改为不显示，但也将负载标记为不显示

UC-开始一条路线 一旦创建并调度了路由，我就可以启动它，这意味着修改路由的状态、停止的状态、有效负载的状态以及关联请求的状态

正如您在用例中所看到的，路由请求和路由表是非常密切相关的，因此首先尽管有单独的聚合根，但请求是AR，路由是AR，路由是AR，但这意味着在同一事务中修改多个AR。 现在让我们看看拥有所有实体的AR是什么样子

class Aggregate {
  constructor(routeData, requests[]) {
  }
}

让我们再来看看加州大学 UC-请求取消

在这个场景中，我只有1个请求数据，所以我必须将routeData保留为空，这听起来不太正确

在这一个我有路由和请求数据，所以我很好

在这一个我有路由和请求数据，所以我很好

这里的主要问题是，一些操作可以在一个请求上完成，一些其他操作将在路由上完成，而另一些操作将在两个请求中都完成。因此，我不能总是通过Id获取聚合，或者我不能总是使用相同的Id获取聚合

不存在“同一事务中的两个聚合根”。事务被限定在单个聚合中，因为理论上所有聚合都应该存在于它们自己的微服务中。以原子方式更新两个或多个聚合的正确方法是