我正在建模一个调度应用程序,并想知道如何避免在一个事务中更新多个聚合根(AR)。我理解在一个事务中更改多个ARs的基本问题,因为它可能导致许多冲突。然而,在我的情况下,我没有其他选择。
时间表大致如下:

我现在的方法是每项任务(T1).T-6)是一个聚合根实例。每个任务都有一个startTime、duration、endTime (不能从startTime和duration派生)和dependentTasks。此外,每个Resource也是一个聚合根。它包含一个配置文件,其中包含资源可用的时间。
适用下列不变量:
假设我想移动T1,那么
因此,计划中的一个动作(T1)会导致所有其他任务的改变!在(好的!)在“实现领域驱动的设计”一书中,通用的答案是“使用最终的一致性”,但我认为这不会解决问题,因为移动任务基本上是一种事务。我不希望有一半的任务已经被移动,另一半由于冲突而处于旧状态。
在实践中,情况会变得更糟,因为计划可以由多个并发用户编辑,但也许这是另一个时间的故事。
是否有办法避免修改一个事务中的多个任务实例?或者,是否至少有办法减少修改/冲突的数量?
发布于 2023-02-16 14:32:15
我不希望有一半的任务已经被移动,另一半由于冲突而处于旧状态。
我可以建议你先问你的用户他们想要什么吗?我可以想象他们对这个问题有不同的看法。
解决调度冲突通常是一种非平凡的操作。这需要时间和思想工作。因此,在实现无冲突调度的过程中,用户必须经过任务重叠或依赖任务被置于错误顺序的中间状态,这似乎是非常自然的。如果应用程序的冲突不是自动解决的,而是由用户手动解决的,则尤其如此。因此,即使计划没有“完成”,用户也需要保存调度的中间状态。
因此,与其试图强迫用户始终没有冲突,不如提供一个可以枚举当前计划中所有冲突并帮助用户逐个解决冲突的操作。在“标记为就绪”、发布或用于其他事情之前,可以重用该函数来检查计划是否没有冲突。或者,您的UI可以在冲突发生时以红色显示计划,而在解决所有冲突时则以绿色显示。
不足为奇的是,这不仅使您的应用程序更易于使用,而且解决了事务的问题,而且还将使多个用户以相同的时间表处理并发更改变得更容易。
进一步考虑一下,您可以在应用程序中提供某些半自动解决冲突的功能。这样的操作将需要一个以冲突作为输入的计划,严格禁止冲突是不容易获得的。
https://softwareengineering.stackexchange.com/questions/444000
复制相似问题