标签: event-sourcing

我正在努力了解通过从EventStore重放事件来重建模型时应该发生的事情,特别是当事件可能触发其他事件发生时.

例如,已经进行了10次购买的用户应该被提升为首选客户并接收向他们提供某些促销的电子邮件.

我们显然不希望每次为该用户重建模型时都会发送电子邮件,但是当我们重播第10个时,我们如何阻止这种情况发生PurchaseMadeEvent呢？

我想使用akka-persistence事件采购功能,以便在我的新项目中实现CRQS +事件采购理念.问题是除了文档(http://doc.akka.io/docs/akka/snapshot/scala/persistence.html)之外,我找不到任何好的示例或指南如何处理它.该文档在解释体系结构的所有构建块(如处理器,视图,通道)方面非常出色,但没有解释如何将它们组合在一起.

所以问题是:如何在akka-persistence中将写模型与读模型连接起来？我想出了三个选择:

• 直接连接Eventsourcedrocessor - > View,View直接从日志中接收所有事件.这似乎是最简单的解决方案,但我想知道我们是否可以使用这种方法在不同节点上分配处理器和视图.

• Eventsourcedrocessor - > Channel - > View/normal Actor.与第一个选项有什么区别？如果这是正确的解决方案,为什么我们在akka-persistence构建块中有视图？我应该使用频道还是PersistentChannels？

• Eventsourcedrocessor - >某种事件总线(例如context.system.eventStream) - > Views/Actors.

什么是最好的方法,为什么？

我正在进行一个新项目的研究阶段,目前我正与一位工作同事就该项目的架构进行辩论.

我们已经同意我们将使用CQRS和使用azure的事件源来创建分布式消息传递系统.它将是一个SPA,前端使用角度js,后端将是Web API.

我们现在讨论了如何设置数据库,这就是发生差异的地方.

我们同意将数据库拆分为两个数据库,一个用于读写.我的同事想要将sql server用于读写数据库,因为他在sql中度过了他的整个职业生涯并且除了sql之外不想听到任何其他内容.另一方面,我一直在研究NoSql,我觉得它适合读取数据库,因为它更适合性能.

由于CQRS完全是关于最终的一致性,我已经读过NoSql数据库也基于此,现在让我考虑将NoSql用于写入数据库.

我们还计划为每个聚合根创建一个事件表,而不是一个包含所有事件的通用事件表.由于这些表不是关系型的,因此我想到为什么我们应该使用sql server.

我的问题更多的是人们如何创建活动商店的最佳实践或一般方法.

1. 您是为所有事件使用一个表还是为每个聚合根创建一个事件表？
2. 将NoSql数据库用于CQRS应用程序的写入和读取数据库的优点/缺点是什么？
3. 最后但并非最不重要的是,您如何说服与Sql结婚的顽固工作同事转换为NoSql方法？

我们目前正在对CQRS和事件采购进行一些研究,并找到了两个主要框架来处理这两个问题:Axon Framework和Eventuate.两者都在不断发展,而现在在RBMH存储库中更积极地开发了Eventuate.

我是GIT克隆了两个示例项目,并得出结论,Eventuate看起来更轻一点,但我认为这是由于缺乏与Axon相比的功能.

我徒劳地试图找到这两个框架之间的比较,在Stackoverflow中我也找不到任何框架.有人有一些意见吗？

CQRS(命令查询责任隔离)和事件采购有什么区别？

我相信Event Sourcing是一种CQRS.每种产品的区别是什么,以及什么使得Event Sourcing与其他类型的CQRS不同？

谢谢,

我对使用域事件构建读取模型的系统中的流程感到有些困惑.特别是,我们如何处理用户期望数据(及其视图)在完成命令时发生更改的事实,但由于我们的系统架构(对发布事件的非阻塞调用),实际数据库可能不会在页面重新加载？

我希望使用事件和服务总线将我们的一个系统的设计与CQRS更加一致.

让我们说我的流程是这样的:

1. 用户单击"查看"中的按钮可执行从其帐户中删除付款方式的任务.

2. 控制器调用PaymentMethodRemovalService,并将其传递给accountId和paymentMethodId.

3. Controller使用AccountRepository检索Account并调用account.RemovePaymentMethod(id)

4. 帐户验证可以进行操作并发布事件PaymentMethodRemovedMessage(accountId,paymentMethodId)

5. 因为事件发布是异步的,所以我们现在必须从服务返回并从控制器返回视图 - 但是我们的实际数据还没有更新!

6. 处理程序IHandle <PaymentMethodRemovedMessage>,检测事件并从数据库中删除实际行

那么,一个人要做什么？

我可以简单地说,删除显示付款方式的div.这可能适用于AJAX场景,但如果我使用Post-Redirect-Get来支持非JavaScript客户端会怎样.然后我将触发我的Get并从查询端读取数据,可能在更新之前.

我是否只是显示一条通知,说明他们已提交删除付款方式的请求？(这似乎不友好,提交订单是有意义的,但不是,例如,更改地址).

有没有办法将实现更改协调为解耦异步事件并显示反映其当前更改的用户数据？

编辑:我的问题非常类似于CQRS,DDD同步报告数据库 我不得不说,那里给出的答案也提到了这里,有一点气味 - 争论用户界面显示一个带外的更新读取DB,可以这么说.我希望有点清洁.

我了解REST +事件采购的基础知识.我从未使用过严格的RESTful API,也没有参与任何Event Sourcing项目.

有人可以解释两者是否可以一起使用？

在事件源中,客户端发送事件,这是否意味着在服务器上有一个事件集合,API的所有POST都将在该集合上,以向其添加事件？

客户端如何发现它可以发送到服务器的命令？

我在我的应用程序中实现了Event Sourcing和CQRS模式.我启发了CQRS之旅,我下载了示例代码.在那里,我找到了事件采购的整个基础设施(CommandHandlers,EventHandlers,事件,信封......等),但它是相当多的代码,我无法想象我需要所有代码用于简单的事件采购.

您是否知道一些常见的测试库/ nuget包/项目,其中包含用于发送/注册命令,事件以及事件源模式中所需的所有基础结构？或者我应该自己实施？

基于CRUD的应用程序部分需要:

1. 离线双向"双向"同步
2. 能够修改数据直到准备好然后"发布".
3. 审核日志

事件采购(或"命令模式")是我正在寻找完成这些项目.我觉得用这个解决2和3感觉很舒服,但对于第一项,同步并不清楚.

如果时间戳用于每个命令(如果需要),那么脱机命令是否需要像实时(合并)一样应用于主系统,或者我可以认为它们应用于任何结束时命令(具有更新的时间戳)？

基于命令的同步的任何基本算法描述都会有所帮助.

在CQRS事件存储中,"聚合"是否包含事件的汇总视图或仅仅是对这些事件边界的引用？(组ID)

投影是事件的视图或表示,因此在聚合表示对我有意义的边界的情况下,而如果聚合包含当前的汇总状态,我会对两者之间的重复感到困惑.