Fel*_*ano 4 design-patterns cqrs event-store
也许这个问题很愚蠢,但我有点困惑.让我们假设我们想要利用这种模式:
企业应用程序中的事件存储范围究竟是什么？
事件存储是在多个进程之间共享,还是只是一个进程内概念？
当应用程序关闭时,事件会发生什么？它们是绑定到应用程序"实例"还是应用程序？
事件存储和MessageBus与发布者/订阅者之间有什么区别(我们可以存储消息历史记录的一部分？
谁对信息幂等负责？
企业应用程序中的事件存储范围究竟是什么？
从这个意义上讲,事件存储就像一个数据库.它不受任何给定应用程序的限制.然而,它可以通过业务/语言边界来确定范围.例如,如果将系统划分为子系统,则每个子系统都可以拥有自己的事件存储实例.
事件存储是在多个进程之间共享,还是只是一个进程内概念？
它不是一个过程中的概念.它就像数据库一样在进程/应用程序之间共享.
当应用程序关闭时,事件会发生什么？它们是绑定到应用程序"实例"还是应用程序？
事件存储将存储应用程序要求它存储的所有事件.事件由流ID键控,流ID通常是聚合根的ID .这不受特定应用程序实例的约束.
事件存储和MessageBus与发布者/订阅者之间有什么区别(我们可以存储消息历史记录的一部分？
消息历史的存储基本上是功能方面的核心差异.用例的不同之处在于消息总线用于在端点之间传递消息,其中事件存储用于持久化消息(通常是事件).
谁对信息幂等负责？
你作为开发者.事件存储将事件视为由流键控的序列化数据,可能还有版本控制.通过版本控制,它可以处理某些冲突,但您需要确定消息是否是幂等的.
我无法理解如何在几个小块中打破一个事务,即使所有事务本身都可以替换分布式事务.
看一下Clarifying the Saga模式.基本思想是,不是在单个分布式事务下对多个操作进行分组,而是将操作分解为多个部分.如果某个部分失败(这将导致分布式tx中的回滚),则会发送错误消息,这可能允许感兴趣的各方进行回滚操作.这可以看作是一种补偿形式,它是分析许多业务场景的更自然的方式.例如,当支付交易被视为无效时,不会删除支付交易,而是添加补偿交易.这种表示活动的方式与现实更加一致,因为实际上很少是"撤消"的东西.
有多少问题!
企业应用程序中的事件存储范围究竟是什么？
事件存储不是一种模式,它是一种通常与两种不同(但强烈相关)模式一起使用的技术:事件源和命令与查询责任隔离.作为"存储",它只是一种保持与业务相关的应用程序状态的方法.
这两种模式通常与域模型结合使用,因为它们与领域驱动设计中 Evans引入的模式配合良好.
EventStore允许您持久保存域事件(事件源方式)或应用程序事件(也称为CQRS中的命令).它与文档和关系存储不同,因为您不保存模型的状态,而是保存导致它的事件.但是,您可以使用RDBMS或文档数据库来存储事件.
然后,为了检索实体,您可以简单地按顺序播放注册的每个事件/命令.快照可用于加快此过程.
事件存储是在多个进程之间共享,还是只是一个进程内概念？
它取决于商店实现,但没有理由阻止它在多个流程和/或应用程序中使用.
当应用程序关闭时,事件会发生什么？它们是绑定到应用程序"实例"还是应用程序？
这又取决于商店的实施.最简单的事件存储将事件保存到编号文件中,因此当应用程序关闭时,事件仍然存在(这总是让我想起汤普森的话:"我们有持久对象,我们称之为文件").
但是,如果您的应用程序确实需要它,那么没有什么能阻止您在内存中拥有易失事件存储.我会将它实现为仅附加收集,保持录入顺序.
事件存储和MessageBus与发布者/订阅者之间有什么区别(我们可以存储消息历史记录的一部分？
消息总线是一种传递消息的工具.事件(和命令)是消息,因此您可以使用它来传递它们.相反,事件存储是一种持久性工具.
谁对信息幂等负责？
在大多数常见场景中,设计域模型的人.在非DDD系统中,它是设计消息(事件或命令)的人.实际上,信息的接收者必须保证幂等性,而不是技术本身.
鉴于此,EventStore可以在检测到重复消息时合并它们.但是,这本身并不能使模型具有幂等性.
这句话实际意味着什么:"有趣的是,即使没有跨越所涉及的各种资源的分布式事务,例如消息队列和持久存储,EventStore也能够确保完全交易体验.这是通过分解来实现的.将分布式事务分成较小的部分并单独执行每个部分"(从这个项目中)我无法理解如何在几个小块中破坏事务,即使所有事务本身都可以替换分布式事务.
这取决于作者赋予"完全交易经验"的含义.对我来说,这句话看起来不对,因为它会破坏布鲁尔定理.
你可以从微软和Greg Young那里找到有用的CQRS之旅.
明天见,在办公室:-)