Question

对于精细的API命令处理，我有一个很好的主意。

我们的Web API应该提供一个简单的update端点，但是您可以为其提供多个命令。像这样：

POST /myAggregate/12345/update
[
  { command1Name: "command1Data" },
  { command2Name: "command2Data" },
  { command3Name: "command3Data" }
]

在Axon中，这似乎很难处理。尤其是结合@AggregateVersion。

我的第一个想法是拥有一个新的UpdateWrapperCommand。内部有一个List commands。然后在Aggregate中，使用反射调用正确的@CommandHandler方法：

class UpdateWrapperCommand {
  List commands;
}

@Aggregate
class MyAggregate {
  // id, version, constructor, etc. pp.

  @CommandHandler
  public void handle(SomeCommand cmd) { ... }

  @CommandHandler
  public void handle(UpdateWrapperCommand cmd) {
    // iterate over cmd.commands
    // iterate over this.getClass().getMethods()
    // find correct method(s), and invoke it
  }
}

但是，当@CommandHandler还使用@MetaData和/或Spring Bean注入时，就会变得非常困难。

我的第二个想法是简单地循环调用commandGateway.send。但这很麻烦，因为必须为每个命令设置@TargetAggragateVersion，并且在发送下一个命令之前，您必须等待每个命令完成。不好。

您对此有什么想法吗？

它应该加载一次聚合，然后运行所有命令。

甚至可能有一些类似事务的行为：应用所有结果事件，或者不应用任何事件。

Answer 1

我认为您最好立即解决此问题，而无需等待已添加到Axon Framework问题跟踪器中的issue，而是添加一个External Command Handler。

外部命令处理程序只是带有@CommandHandler批注功能的常规组件。该方法将处理您的UpdateWrapperCommand，并且知道为包含它的每个命令有效负载发出单独命令的工作。

您所建议的Aggregate的加载优化实际上与实现批处理命令解决方案相关。尽管在框架中这绝对是可行的，但此功能尚不存在。我建议您继续跟踪自己创建的issue，以跟踪其进度。

希望这可以帮助您摆脱本杰明！

Answer 2

如果事务意味着全部或全部，则可能没有很好地建模每个命令的边界。

在不了解域的情况下，我会说选项是：

1将所有命令仅包装成一个，并应用于一个全部处理的集合。

2独立应用所有命令，如果出现任何故障，请应用补偿措施。

3根本不使用命令，而只是将事务逻辑应用于更简单的事物上。

Axon：适用于单个聚合的多命令

2 个答案: