何时使用Eventstore

Question

我不太清楚我理解Eventstore是什么,我认为它是Domainobjects的某种"Transactionlog".它的优点/缺点是什么？使用它的好方案是什么,什么时候不应该使用它？

编辑:

既然我可能要求太多,我会很高兴,如果有一个"简单"的场景何时使用eventstore而不是？换句话说:是否可以用一些句子来描述这两个场景,或者我是否需要阅读5本书来理解它？

Answer 1

是的,事件源就像是域对象的事务日志,事务日志是所有数据的权威来源.您可能拥有其他形式的数据副本,以便于查询,但它们只是可以随时删除和重建的副本.事务日志是事实的唯一来源.

我同意Craig的说法,很难简洁地回答你的问题,因为它非常依赖于上下文,但这里列出了为什么你可以考虑使用事件存储的简短列表:

• 您关心对数据进行复杂的历史分析.例如,有人可能会在未来找到你并问:"我们有多少客户将商品放入购物车,然后把它拿出来,但在我们寄给他们一张优惠券后,又回来买了它？" 可以提供无穷无尽的BI问题,你无法提前预测所有这些问题.如果捕获系统中的所有事件,则可以重建未来任何问题的答案.
• 同样,您关心审计并能够毫无疑问地证明谁在何时以及为何更改了哪些数据.您的事件存储是您的审核日志.
• 您关心拥有高度可扩展的系统.由于事件存储的写入模型仅附加,因此它非常适合大批量应用程序.因为它本身并不是关系型的,所以通常可以很容易地进行分区.

另一方面,有一些很好的理由不这样做:

• 您没有上面列出的任何需求.
• 您不想处理必须构建调试工具以便能够轻松查看和修改事件存储中的数据的麻烦.
• 您正在构建一个短期项目,您不希望长时间存在,因此您不希望投入大量的架构工作.
• 您不准备在事件采购的同时学习CQRS,DDD和EDA.事件采购并不严格要求这些想法,但它们经常交织在一起,当您完全改变范式并将它们全部用在一起时,就会找到真正的价值.事件采购是一系列技术的一部分,这些技术共同代表了一种非常不同的软件架构思维方式.这可能是令人生畏的.

Answer 2

这在stackoverflow问题中要求很多.你的问题遗漏的一件事是它的缺点是什么？无论如何,我想提供一些视频链接供你观看,而不是在这里回答.在对这个问题的答案有意义之前,需要设置很多上下文.

Greg Young的:有1〜2个小时的视频在这里提供你在你的问题,要求所有的很好的概述.还有一个约6小时的在线类在这里.

乌迪大汉:有一个1小时的视频在这里,让在何时使用这些技术的视角.

邮件列表:有一组在这里,你可以问你所有的问题,并有围绕主题一个很好的讨论.

希望这是有帮助的.你的问题中有很多内容,我认为你不会或任何其他任何人试图用一个简短的dia骂和误导人来回答它.

更新:我认为你不需要阅读5本书,甚至不需要查看下面的视频.我认为这样做非常值得,但不是必需的.您的问题是"简单"场景通常不需要事件源.大多数应用程序主要是CRUD和数据驱动.也许这是你问题的答案.如果您的系统中没有太多"行为",那么您不需要它.如果有很多行为,那么您可能需要它.