CQRS中单个进程的多个命令

Question

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

无论如何我的问题是：

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

1. 创建用户配置文件命令
2. CreatePaymentAccount 命令
3. SendEmailAddressVerificationCommand

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

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

更新 @EbenRoux
要添加更多信息，CreatePaymentAccount 实际上应该命名为 UpdateUserWithPpaymentAccount。我看到命名的混乱。该命令实际上确实获得了第 3 方并获得了附加到用户的 PaymentCustomerId。

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

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

Answer 1

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

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

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

从User BC 发布UserProfileCreatedEvent，您的进程 BC 订阅，UserRegistrationProcess 被更新，流被保存，CreatePaymentAccountCommand 被发送到Payment BC。这是一个系统消息（事件）的示例，它的结构可能与为 ES 方面产生的任何东西有些不同。

现在从Payment BC 发布PaymentAccountCreatedEvent，它也被进程 BC 订阅，SendEMailAddressVerificationCommand 被发送到相关的 BC。

出现了相当常见的模式。

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

Answer 2

事件不是噩梦，它们只是现实生活中事物的运作方式。如果您发送一封信，您无需等待回复，您将继续您的生活，当您收到回复时，您会拿起这封信并阅读它。

你确实可以使用 Saga。

1. 使用 CreateUserProfileCommand 启动 saga
2. 发布一个新事件 UserProfileCreatedStarted 并让 Payments 服务监听该事件
3. 让注册传奇订阅“PaymentAccountCreatedEvent”
4. 在注册过程完成后发布UserProfileCommandCreated
5. 发布“UserProfileCommandCreated”并完成传奇和
6. 让您的通信服务订阅 UserProfileCommandCreated 并发送电子邮件

看看这个例子：Saga implementation patterns – variations

您要避免的一件事是服务之间的耦合，而这正是您在域中使用大量命令时发生的情况。通常命令是由用户或系统内部的一些“触发器”生成的，即：ChargeMontlyInstallment

至于事件源，因为这对你来说是全新的，请看这里：best event sourcing db strategy

Answer 3

这只是一个用例吗？即创建用户配置文件？

我想知道为什么不只有一个命令 CreateUserProfile，然后由协调用例的命令处理程序处理。其他一切都将成为事件，即PaymentAccountCreated、EmailNotificationSent 等...

如有必要，您可以使用此命令启动进程管理器，但这取决于您还需要处理什么以及如何返回外部调用。即它是一个简单的请求/响应还是外部系统调用您的 API 等