J Olivers 活动商店 - Saga 帮助
我正在尝试使用 Jonathan Olivers EventStore 和 CommonDomain 来了解 Saga。我了解聚合如何与 CommonDomain/EventStore 配合使用，但我一直坚持掌握 Saga 的用法。我读过 Jonathan 的 Saga 的事件溯源第一部分和第二部分。 II 但在实际实现中仍然丢失
1）更多的观察，当持久化传奇时，EventStore正在利用标头来持久化需要发送的传奇和命令，并且看起来有效负载正在存储触发传奇的事件“醒来”。想知道这样做的原因。我们是否永远不想存储单个命令而不是将它们全部放在标头中？
1）似乎触发Saga的事件会重播多次，因为SagaBase中的“Transition”方法总是将事件重新添加到未提交的集合中。 （与具有内部 Apply 方法和公共域方法的 AR 不同）。也许我没有正确使用 Transition 方法
2) 通常，您与 EventStore 一起使用的总线将发布事件（我实现了 IPublishMessages）。如果我需要我的 Saga 发布命令，则似乎没有“发送”选项。我是否需要解析标头才能自己获取命令？
我认为我错误地使用了 CommonDomain / EventStore，因为使用聚合很容易，但 Saga 对我来说似乎“不完整”。我假设是因为我做得不正确。对于 CQRS 来说还很陌生。有人有 Saga 使用 J Olivers 公共域/事件存储的工作示例吗？我认为这会大大澄清事情。
[编辑] 我想我已经弄清楚了，但希望得到一些意见。 Saga的确实不应该发布事件。他们发出命令。因此，在 EventStore (IPublishMessages) 的发布方面，我应该首先检查消息类型（AggregateType 与 SagaType），对于 AggregateTypes，我可以发布事件，但对于 SagaTypes，仅发布命令（在标头中找到）。这消除了触发 Saga 创建的同一事件（例如 OrderSubscribedEvent），以便在持久化 Saga 时不再发布它。
I am trying to wrap my head around Saga's using Jonathan Olivers EventStore and CommonDomain. I understand how Aggregates are working with the CommonDomain/EventStore but I am stuck on grasping Saga usage. I have read both of Jonathan's Saga's with Event Sourcing Part I & II but sill lost in actual implementation
1) More of observation, when persisting the saga the EventStore is utilizing the Headers to persist the Saga and Commands that need to be sent out and it looks like the Payload is storing the Event that triggered the Saga to "wake up". Wondering reasons for this. Would we never want to store individual commands vs having them all in the header?
1) It seems like the Event that triggered the Saga gets replayed multiple times since the "Transition" method in SagaBase always re-adds the event to uncommitted collection. (Unlike ARs that have an internal Apply method vs public Domain method). Maybe I am not using the Transition method properly
2) Typically the bus that you use with the EventStore will publish Events (I implemented IPublishMessages). If I need my Saga to publish a command there does not seem to be a Send option. Do I need to parse the Headers to grab the commands myself?
I am thinking I am using the CommonDomain / EventStore incorrectly as working with Aggregates was easy but Saga's seem "incomplete" to me. I am assuming its because I am not doing it correctly. Still very new to CQRS. Does anyone have a working example of Saga's using J Olivers Common Domain / Event Store? I think that would clear things up considerably.
[EDIT]
I think I figured it out but would like some input. Saga's really should not be publishing events. They send out commands. Thus on the publish side of things for the EventStore (IPublishMessages) I should first be checking the type of message (AggregateType vs SagaType) For AggregateTypes I can publish Events but for SagaTypes only publish the commands (found in Header). This eliminates the same event (say OrderSubmittedEvent) that triggers the creation of the Saga to not publish it again when persisting the saga.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
命令被放入要在总线上发送的标头中。 EventStore 负责事件的存储，以便持久保存导致 saga 转换的事件。稍后，当从事件流加载 saga 时，事件将被传递到 saga 的转换方法以使其进入当前状态。
转换方法在 saga 实现中具有双重目的。调用 Transition 来处理传入消息并从持久性中加载传奇。在 SagaEventStoreRepository.BuildSaga 中，在构建当前状态后，将在 saga 上调用 ClearUncomiedEvents 和 ClearUndispatchedMessages，从而避免重复的事件和命令处理。
我个人没有这样做过，但我会为我的传奇使用单独的 EventStore 实例。这将允许使用单独的 IPublishMessages 实现来从事件标头获取命令并发送它们。
The commands are put in the headers to be sent on the bus. The EventStore is concerned with the storage of events so the events that caused saga transitions are persisted. Later, when the saga is loaded from the event stream, the events will be passed to the saga's transition method to bring it to the current state.
The transition method serves a dual purpose in the saga implementation. Transition is called to handle incoming messages and to load the saga from peristence. In SagaEventStoreRepository.BuildSaga ClearUncomittedEvents and ClearUndispatchedMessages are called on the saga after the current state is built up thus avoiding duplicate event and command processing.
I haven't personally done this but I would use a separate EventStore instance for my sagas. This would allow for the usage of a separate IPublishMessages implementation to take the commands from the event headers and send them.