我有CQRS + ES设计的应用程序。这是我新的CQRS + ES世界在过去的一年中一直在阅读它并且它非常有意义，但实现完美的感觉并不容易。
无论如何，我的问题是：
包含多命令（步骤）过程的最佳方法是什么？即注册用户这些是我想在该过程中触发的命令：
我看过Saga，他们看起来更开始和停止然后这个过程都是连续的。
当然，链接事件的步骤会导致重播噩梦。
更新 @EbenRoux
要添加更多信息，CreatePaymentAccount实际上应该命名为UpdateUserWithPpaymentAccount。我看到命名中的混乱。这个命令实际上是什么让第三方得到了一个附加给用户的PaymentCustomerId。
我得到了你对佐贺的看法，我想知道这个过程是否需要。
现在这个应用程序正在进行中所以所有的业务环境（我假设你是BC的意思）没有一个端点pub / sub立场。我想到达那里。
答案 0 :(得分：4)
请记住，不会重播命令。在我理解的这个阶段，我认为系统/域消息与事件源（ES）中使用的事件不同。 ES事件代表国家。他们不应该参与任何处理。它们永远不会导致执行命令或以任何方式导致执行命令。它们只是保持域模型状态的另一种方式。
您的流程管理员（有时被称为 saga ）将成为另一个流程的有限上下文（BC）中的一等公民，协调系统消息传递并其 em> state当然也可以使用ES存储。
您可以将相同的消息（如果您愿意）路由到不同来源的不同端点。例如：从您的前端/集成层，您可以发送CreatUserProfileCommand，并且路由将其发送到您的进程BC，其中处理程序创建新的UserRegistrationProcess，存储流并发送{{1现在路由到CreateUserProfileCommand BC。
从User BC User发布您的流程BC订阅并UserProfileCreatedEvent更新，流已保存，UserRegistrationProcess已发送到公元前CreatePaymentAccountCommand。下面是一个系统消息（事件）的示例，它可能具有与为ES方面生成的任何内容稍有不同的结构。
现在从Payment BC发布了Payment，它也被进程BC订阅，PaymentAccountCreatedEvent被发送到相关的BC。
出现了一种常见的模式。
因此，您可以避免任何重播噩梦，因为问题明确分开。
答案 1 :(得分：2)
事件不是噩梦，它们只是现实生活中的事物。如果你发一封信，你不等待回复，你继续你的生活，当你回复时，你会收到这封信并阅读。
你确实可以使用Saga。
看一下这个例子：Saga implementation patterns – variations
您要避免的一件事是服务之间的耦合，而这恰恰是您在域中使用大量命令时发生的事情。通常命令是从用户生成的，或者是由某些＆＃34;触发器生成的。在该系统中，即：ChargeMontlyInstallment
至于活动采购，因为这对你来说都是新的，请看一下：best event sourcing db strategy
答案 2 :(得分：0)
这仅仅是一个用例吗？即创建用户配置文件？
我想知道为什么不只有一个命令，CreateUserProfile然后由一个编排用例的命令处理程序处理。其他一切都将成为事件I.e. PaymentAccountCreated，EmailNotificationSent等......
如果需要，您可以使用此命令启动进程管理器，但这取决于您需要处理的其他内容以及返回外部调用的方式。即它是一个简单的请求/响应，还是外部系统调用您的API等