涉及多个聚合的业务逻辑走向何处？

Question

当涉及到领域驱动的设计时，我仍然是一个初学者，我正在尝试将一些类似于RPG的战斗系统建模作为一个有限的上下文。我试图建立一个有限度的上下文模型，在这个上下文中，一个战斗人员有一个能力列表，而每个能力都有一个可以应用的效果列表。例如，一个共同的效果将是对目标战斗人员造成伤害。

据我所知，这两个聚合根是战斗力和能力，其效果是一个值对象。

现在，我不知道我应该把我的逻辑放在战斗人员之间的互动上。特别是，我需要在考虑到源Combatant和目标Combatant的情况下处理执行能力的逻辑。同样，对于能力的个别效果，我也需要类似的逻辑。由于操作和效果是由战斗人员的一个实例造成的，并且是针对Combatant的第二个实例，所以我不认为这个逻辑应该在Combatant聚合本身内完成。

问题是，我只是不知道逻辑应该去哪里。一开始我认为域名服务是正确的，但经过研究后，我认为我可能是错的。有人知道我应该把这个逻辑放在哪里吗？

Answer 1

协调涉及多个集合的流程的业务逻辑应该留在Saga/过程管理器中。这并不意味着所有的逻辑都应该停留在这里。不是的。只有协调逻辑。实际的实现取决于编程语言和体系结构，但我可以给您和示例。

例如，假设一个战斗人员对其他战斗人员造成伤害(火灾)。点火过程由Saga处理。但是每个战斗人员都应该有两种指挥方法：inflectDamageTo和getDamagedBy。Saga加载shooter聚合，调用shooter.fireAt(shootedId, effect)并持久化更改。然后，它加载shooted聚合，调用shooted.getDamagedBy(shooterId, effect)，并持久化更改。

无论是在每一步之前还是之后，萨加都可以坚持自己的进步。这可能和Enum一样简单。这样做是为了获得足够的信息，以便在发生故障时恢复，并强制停止Saga (即进程停止、服务器重新启动等)。

请记住，在这个过程中，您有两个事务，不只是一个(或者没有，取决于持久化的类型)。另外，注意每个聚合只接收另一个聚合的ID，而不是一个完整的引用。

在某些领域，性能比代码的可维护性或数据的一致性更重要；我的回答基于这样一个事实:您已经分析了您的业务需求，并且仍然希望使用DDD方法。