NEventStore：Sagas，Commands而不是丢失他们

Question

NEventStore：5.1
简单设置：WebApp（Asp.NET 4.5）==命令端

我正在寻找＆＃34;对＆＃34;不要失去命令的方法，关注传奇/流程管理者，这可能会无休止地等待一个实际上从未处理过的命令产生的事件。

旧：调度员

我最初使用同步命令，但着眼于 sagas / process-managers 我认为首先存储它们然后通过SyncDispatcher（或AsyncDispatcher）获取它们会更安全< / strong>即可。否则，这是我的担心，如果一个传奇会尝试发送一个命令并且该命令由于 app-crash / powerloss /...而没有完成，那么它将是失去了，没人会知道。

所以我创建了一个命令流并将每个命令附加到该命令。如果已经处理了该命令，IsDispatched显示 这很有用。

PollingClient和Command-Stream

现在调度员已经过时，我切换到 PollingClient 。我遗失的是Dispatched信息。

出现启动问题：
我从当前最新的检查点 继续 开始开始轮询，但是当应用程序重新启动时，有可能存储了命令，但之前没有执行崩溃，因此失败（实际发生）。

我刚刚遇到了想法：
 将命令的基本结果存储为另一个流中的（非域）事件 此信息流将包含CommandSucceeded和CommandFailed个事件 每当应用程序启动时，最新的command-id或command-checkpoint-number被提取，用于在那之后加载命令......

问题

• 我的担忧是，同步命令处理导致丢失传奇生成的命令的危险，错了吗？如果是，为什么？
• 这通常是一个好主意：一个大命令流？
• 这通常是个好主意：在流中存储通用命令结果事件吗？

Answer 1

你可以：

1. 将命令存储在命令队列中持久性日志
2. 使用命令id（guid）作为NEventStore上的Commit Id
3. 将您的命令标记为在Command Handler中执行管道钩|投票客户

NEventStore为您提供相同的AggregateId（streamid）+ CommitId的幂等性，因此如果您在命令被标记为已处理之前应用程序崩溃并且您重放命令，则NES会自动丢弃生成的提交。

Answer 2

Afaik NEventStore旨在成为事件源的存储，即将域对象存储为事件流。命令和传奇与它无关。这是你的服务总线，应该考虑到耐久性和传奇管理。

就个人而言，我将事件存储简单地视为存储库细节。应用程序服务（命令处理程序）将在生成的事件被持久化后调度它们。

如果应用程序崩溃并且服务总线是持久的（不是内存），那么将自动再次处理事件/命令，因为服务总线应该检测消息是否未成功处理。当然，您的消息处理程序应该是幂等的。