cqrs - CQRS 中单个进程的多个命令

Question

我有 CQRS+ES 设计的应用程序。这是我在过去一年里一直在 CQRS+ES 世界中阅读的新内容，它非常有意义，但实现完美的意义并不总是那么容易。

无论如何，我的一个或多个问题是:

包含多个命令(步骤)流程的最佳方法是什么？即注册用户，这些是我想在该过程中触发的命令:

1. 创建用户配置文件命令
2. 创建付款帐户命令
3. 发送电子邮件地址验证命令

我看过 Saga 的，他们看起来更像是开始和停止，然后这个过程是连续的。

当然，链接事件步骤可能会导致重播噩梦。

更新 @EbenRoux
要添加更多信息，CreatePaymentAccount 实际上应命名为 UpdateUserWithP paymentAccount。我看到命名中的困惑。该命令实际上获取第三方并获取附加到用户的 PaymentCustomerId。

我明白你对 Saga 的看法，我想知道这个过程是否需要这样做。

现在这个应用程序刚刚开始，所以所有的业务上下文(我假设这就是你所说的 BC 的意思)都没有一个端点 pub/sub 的立场。不过我很想去那里。

Answer 1

请记住，命令不会重播。在我的理解的这个阶段，我认为系统/域消息与事件溯源(ES)中使用的事件不同。 ES 事件代表状态。他们不应参与任何处理。它们永远不会导致命令被执行或以任何方式导致命令被执行。它们只是保存域模型状态的另一种方式。

您的流程管理器(有时称为saga)将是另一个流程限界上下文(BC)中的一等公民，负责协调系统消息传递及其 em> 状态当然也可以使用 ES 来存储。

您可以将相同的消息(如果您愿意)从不同的源路由到不同的端点。例如:从您的前端/集成层，您可以发送CreatUserProfileCommand，路由将其发送到您的进程BC，其中处理程序创建一个新的UserRegistrationProcess，存储流并发送现在路由到 User BC 的 CreateUserProfileCommand。

从 User BC 发布您的流程 BC 订阅的 UserProfileCreatedEvent，并且更新 UserRegistrationProcess，保存流，并且CreatePaymentAccountCommand 被发送到 Payment BC。下面是一个系统消息(事件)的示例，其结构可能与为 ES 方面生成的任何内容有所不同。

现在，从 Payment BC 发布 PaymentAccountCreatedEvent，该事件也由流程 BC 订阅，并且 SendEMailAddressVerificationCommand 被发送到相关的公元前。

出现了一种相当常见的模式。

因此，您可以避免任何重播噩梦，因为关注点是明确分开的。