如何解决我们应该将事件存储在数据库中吗？ 事件驱动设计
我们有一些服务可以发布和订阅域事件。通常，我们在发布时记录事件，在处理事件时记录事件。我们基本上使用它来应用编排模式。
我们不在这些系统中进行事件源搜索，并且在发布/处理后也没有程序化的用途。这是我们选择不将其存储在数据库或事件存储之类的持久容器中的主要驱动程序。
问题是，这样做是否使我们错过了一些基本的东西？ 是否必须存储事件？
解决方法
我将排队的消息视为系统消息，即使它们表示事件驱动的体系结构（发布/订阅消息）中的某些域事件。
关于它们的存储，绝对没有严格的规定。如果您希望保留它们，则可以让您的消息传递机制将它们转发到某个审核端点进行存储，然后在一段时间后将它们删除（如有必要）。
通过 not 存储它们，您不会丢失任何基本信息。
,您绝对不会错过任何（但有一个陷阱）的东西，尤其是在企业不需要的情况下。 Event-Sourced System肯定会将系统生成的所有事件存储到database（或任何其他事件存储）中
事件存储的主要用途是在发生故障的情况下能够通过重播消息将系统状态恢复到当前状态。为了使恢复过程更快，我们提供了快照。
在您的情况下，由于这些事件仅在流程完成之前才相关，因此直到失败后再存储它们是没有意义的。 （这是要注意的问题） ，尤其是在“分布式事务”案例中。
我会提出什么建议？
- 不要自己存储事件，而是记录有关这些事件的相关详细信息，并可以使用
ELK stack或Grafana来存储这些日志。 - 在进行分布式事务处理时，请使用
Saga Pattern或Routing Slip pattern并记录它们。 - 如果在处理事件时发生故障，请将该事件放入
exception queue中并进行处理。如果这是分布式事务的一部分，请确保它们全部具有相同的TransactionId或它们具有CorrelationId，以便您可以查找日志并保存系统。
要在分布式架构中可靠地执行业务交易，您需要以某种方式确保事件至少发布一次。
因此，发布事件的服务需要将该事件保留在导致创建事件的同一事务中。
考虑到您是通过基础结构服务（例如消息传递服务）发布事件，因此不能一直依赖于该事件。
此外，您自己的服务实例可能会在 之后关闭，并保留您新创建或更改的聚合，但 之前 它有机会通过消息服务发布事件。
问题是，这样做是否使我们错过了一些基本的东西？是否必须存储事件？
您没有在进行事件采购也没关系。除非从业务角度来看，有时 永远丢失事件 是可以的，否则您需要通过 local 事务暂时保留事件，直到事件发布为止
您可以查看 Transactional Outbox Pattern 以实现可靠的事件发布。
注意：以某种方式记录/跟踪事件以进行监视或稍后分析/报告目的是另一回事，并且有另一种动机。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。