Events 指令中的相关性和因果关系ID

Greg Young，作者，引用消息根本原因的关联ID和引用消息直接原因的因果ID

因此，您应该能够通过另一条消息的因果关系ID找到另一条消息直接响应的消息。并且您应该能够通过具有相同因果关系ID的消息找到同一对话中的所有消息

如果应用了此模式，会话中的第二条消息应该将相关ID和因果ID都设置为第一条消息

在Commanded中，我希望第一个事件同时具有相关ID和因果ID，以指向导致事件发生的命令（也可以直观地描述）

令人困惑的是，在Commanded自己的事件存储中，似乎命令后的第一个事件具有不同的相关性和因果ID。所以这似乎不适用格雷格·杨的定义

我的问题是，这些ID的确切定义是什么？不遵循Greg Young的定义是否是一个有意识的决定，如果是，原因是什么？

已按照下面复制的指南中所述实施

默认情况下，命令不会被持久化，因此，除非您还持久化传入的命令，否则无法遵循“命令>事件>命令”的因果链。您可以使用将调度的命令存储到任何支持EXTO的数据库中。这样做将允许您将命令及其结果事件绑定在一起。关联id还可用于关联所有相关消息，假设您在发送命令时复制这些消息。下面给出了一个这样做的例子

在Greg的事件存储中，我认为因果关系id是从一个事件复制到另一个事件的，忽略了中间命令，因为他的事件存储只是存储事件

---

相关性和因果关系 为了帮助监视和调试已部署的应用程序，跟踪命令和事件的原因和关联ID非常有用

• 因果关系\u id

  -导致事件的命令的UUID，或导致命令分派的事件

• correlation\u id

  -用于关联相关命令/事件的UUID

您可以在发送命令时设置因果关系和关联ID：

:ok = ExampleRouter.dispatch(command, causation_id: UUID.uuid4(), correlation_id: UUID.uuid4())

在事件处理程序中调度命令时，应从正在处理的事件中复制以下值：

defmodule ExampleHandler do
  use Commanded.Event.Handler, name: "ExampleHandler"

  def handle(%AnEvent{..}, metadata) do
    %{event_id: causation_id, correlation_id: correlation_id} = metadata

    ExampleRouter.dispatch(%ExampleCommand{..},
      causation_id: causation_id,
      correlation_id: correlation_id
    )
  end
end

---

流程管理器发送的命令将自动从源域事件中分配适当的因果关系和关联ID。

感谢您的澄清。但我仍然想知道为什么在第一个事件中，相关性和因果关系不一样。这是否意味着关联ID只是一个随机值，而不是命令或事件的ID？关联ID用于关联相关消息（命令和事件）。如果在命令分派期间不提供它，它将被设置为随机UUID。例如，您可以决定使用特定于应用程序的关联id（例如，

order\u id

或

reservation\u id

）来帮助以易于识别的方式将相关消息关联在一起。而因果id是前一条消息的标识，允许您随着时间的推移跟踪一系列消息。对于任何未作为对事件的反应触发的命令，它将被取消设置（

nil

）。遗憾的是，相关ID始终需要是UUID。因此，通常不可能将其设置为与业务相关的内容。看见