事件采购条目应包含什么更新视图模型或事件的有效载荷？
我有一个来自第三方服务的数据。它正在传递到将数据格式化的函数传递到以我可以为系统可视化的方式将其保存到视图模型的函数。
在事件驱动的方法中，如果我在事件流中保存请求的有效载荷（可以很容易地偿还），或者它将其产生的格式化更改为视图模型（数据的当前状态更准确表示） ？
还是其他东西？
谢谢
I have a situation where data is coming from a third party service. It is being passed through to a function that formats the data and then saves it to a view model in a way that I can visualize for my system.
In an Event driven approach, should I save the payload of the request (as this can easily be repayable) in the Event stream, or the formatted changes it produces to the view model (a more accurate representation of the current state of the data)?
Or something else completely?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
传入数据可以看作是表达最终更新某些状态的意图的命令。在这种情况下，该命令来自我们的系统外部，但是命令也可以是我们系统的内部。特别是对于外部命令，要记住的一件关键是可以拒绝命令。
但是，在事件采购中，事件是内部的，并表明发生了变化，并且不能否认（最多可以忽略它）。因此，最好将它们存储在最方便的内部用途的格式中。
我将这些请求描述为命令和格式化更改为事件。保存有效负载是命令采购，保存格式化的更改是事件采购（令人困惑的是，福勒对事件采购的最早描述更像是命令采购），两者都是有效的方法。事件采购倾向于暗示重播类似状态的承诺，而命令采购的叶子为重播的能力开放，以依靠外界的事物。我已经看到（并开发了）使用两种技术的应用程序（例如，将传入数据倾倒到Kafka，消费者将这些消息视为针对骨料的命令，其状态被认为是一系列事件，这些事件被投影回KAFKA）。
如果您（以CQRS/ES的方式）将应用程序的读取端视为与写入侧的独立自主组件，那么您得出一个有趣的结论，即当写入端从读取方面发表事件时，从读取方面的角度来看它是向阅读端的发布命令。 “一个组件的事件通常是另一个组件的命令”。
The incoming data can be viewed as a command expressing the intent to ultimately update some state. In this case the command is from outside our system, but commands can also be internal to our system. Especially for external commands, one critical thing to remember is that a command can be rejected.
In event sourcing, however, events are internal and express that the change has occurred and cannot be denied (at most it can be ignored). Thus it's probably best to store them in the format that is the most convenient for that internal use.
I would characterize the requests as commands and the formatted changes as events. Saving the payload is command sourcing, saving the formatted changes is event sourcing (confusingly, Fowler's earliest descriptions of event sourcing are more like command sourcing) and both are valid approaches. Event sourcing tends to imply a commitment to replay to a similar state while command sourcing leaves open the ability for replay to depend on something in the outside world. I've seen (and developed even) applications which used both techniques (e.g. incoming data is dumped to Kafka, a consumer treats those messages as commands against aggregates whose state is persisted as a stream of events, which gets projected back into Kafka).
If you (in CQRS/ES fashion) consider the read-side of your application to be a separate autonomous component from the write-side, then you reach the interesting conclusion that when the write-side publishes events, from the read-side's perspective it's publishing commands to the read-side. "One component's events are often another component's commands".