问题标签 [event-sourcing]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
c# - CQRS/EventStore 幂等性?
使用 Jolivers EventStore 在 c# 中实现/处理幂等性。这是否意味着在处理之前只需检查域/读取模型旁边的聚合 ID 和版本?或者还有更多的东西吗?
[编辑]
我问的原因是,例如,我想以小功能块开发我的应用程序。
所以 - 想象一下我有一个包含在线商店产品数据的某种类型的数据集。我想通过创建搜索产品的能力来开始开发应用程序。这意味着以某种方式导入数据集(不管如何)。数据集中的每个产品最终都会触发(例如)一个 CreateProductCommand - 此命令通过触发 ProductAddedEvent 的域,然后由非规范化程序处理以填充 ProductSearchView
现在 - 实现搜索功能后,我想创建产品详细信息视图。我已经运行了导入以将数据集导入系统,因此我想重新运行将触发非规范化器以填充 ProductDetailView 的事件
那有意义吗?
cqrs - CQRS/EventStore:如何处理事件传递失败?
进入 CQRS,我知道你有命令(应用层)和事件(来自域)。
在事件要更新读取模型的简单情况下,读取模型更新会失败吗?如果没有“错误”,那么我看不到它们失败,并且当我使用 EventStore 时,我知道有一个提交标志将重试失败。
所以我的问题是除了 EventStore 之外我还需要做任何事情来处理故障吗?
来自一个您在一次交易中完成所有事情而现在事情分开完成的世界让我担心。
sql-server - 从 SQL Server 生成事件
我正在寻找一个最佳实践或示例,说明我如何能够为给定 SQL Server 2008 R2 db 上的所有更新事件生成事件。为了更具描述性,我正在开发一个 POC,我基本上会将更新事件发布到一个队列(在我的例子中是 RabbitMq),然后可以由各种消费者使用。这将是通过事件溯源实现 CQRS 仅查询数据模型的第一部分。通过放置在 que 上,任何人都可以订阅这些事件以复制到任意数量的仅查询数据模型中。这部分很清楚并且定义相当明确。我遇到的问题是确定从 SQL 服务器生成事件的最佳方法。我得到了一些想法,例如监控事务日志和 SSIS。但是,我不完全确定这些选项是否可行甚至可行。
有没有人对这种事情有任何经验或对如何进行这样的冒险有任何想法?任何帮助或指导将不胜感激。
unit-testing - 没有 getter/setter 的 TDD 行为测试
我正在将 TDD 应用于我的第一个以事件为中心的项目(CQRS、事件溯源等),并且我正在根据 Greg Young 的简单测试框架 Given、When、Expect 编写测试。我的测试夹具接受一个命令、命令处理程序和聚合根,然后测试输出的事件。
例如这里是一个典型的测试
总的来说,我对这些测试非常满意,但是在上面的测试中我遇到了问题。聚合根包含一组组。该命令MoveGroup
对集合进行重新排序,采用 from & to 索引。我设置了测试并断言GroupMoved
使用正确的数据生成了正确的事件。
作为一项附加测试,我需要断言 Groups 集合的重新排序实际上是正确进行的?当聚合根没有公共 getter/setter 时,我该怎么做。我可以添加一种方法来检索特定索引处的组,但这种破坏性封装不是只是为了可测试吗?
这样做的正确方法是什么?
编辑
组的重新排序发生在 Aggregate 根上的 GroupMoved 处理程序中。
c# - 如何使用事件溯源模式处理事件处理程序中的代码修改
我正在尝试使用事件溯源模式,但有一件事让我很困扰。
如果我更改某些事件处理程序的源代码会怎样规则检查。
这是否意味着事件处理代码应该是不可变的?(一旦你写了它,你就再也不会碰它了)。我真的不喜欢这个主意。
经过不久的研究和思考,我得出结论,Event 是一个消息,并且像 SOA 中的任何消息一样,它应该是版本化的。
cqrs - 事件溯源和追溯事件
我需要将追溯事件合并到我的事件流中,但我不确定实现它的最佳方式。
我们需要保持原始事件流不变以进行审计和所有其他标准好处。事件流本质上也是暂时的,使我们能够查看历史上任何一点的值。即 x 的值在 6 月 1 日下午 5 点为 10.00。有时我们会在 6 月 5 日发现 x 的值实际上是 6 月 1 日下午 5 点的 12.00。在这种情况下,我们将 10.00 称为“as-at”值,将“12.00”称为 as-of 值,并在事件流中跟踪这两个值。
为 as-at 值重建状态是直接查询 6 月 1 日下午 5 点之前的最新快照以及 6 月 1 日之前的所有事件。
我犹豫的地方是重建现状。如果对模型进行了 as-of 更正,那么默认情况下应该使用它而不是 as-at,但是如果不读取整个事件流,我看不到任何方法来确定是否存在 as-of更正从时间点到现在(这可能很大),并且大多数更改都无关紧要,因为它们将与未来的更改相关,而不是相关的时间点。
我应该在这里看看不同的方法吗?
谢谢,克里斯
domain-driven-design - 我们真的需要一个带有事件溯源和 CQRS 模式的独立事件存储吗?
假设我们需要实现一些需要检查对象历史(事件存储)的域规则。例如,我们有一个带有 CurrentStatus 属性的 Order 对象,我们需要检查 Order.CurrentStatus 更改历史记录。
您很可能会回答我需要将这些知识转移到领域并引入包含状态记录集合的 Order.StatusHistory 属性,并且我不应该查询事件存储。我会同意你的。
我的问题是 Event Store 的需求。
我们在事件存储中写入具有业务意义(领域价值)的事件,我们不记录 UserMovedMouse 事件(在大多数情况下)。与 OrderStatusChanged 事件一样,很可能在某些时候需要来自 EventStore 的大多数事件用于域逻辑,我们最终会得到一个域对象,该对象具有 EventHistory 属性和事件集合。
当您有单个只写事件存储和多个只读查询存储时,我可以在单独的事件存储中看到 CQRS 等模式的值,这为您提供了一些可伸缩性。然而,在代码中引入这样的东西对我来说也是个问题。所有像样的数据库都支持单写服务器、多读服务器的可扩展性(主从复制)。为什么我要在源代码级别引入这样的东西?为什么不忘记 Web 服务和消息总线,并使用编写自己的 Sockets 包装器。
我非常尊重“老派” DDD,因为它被 Eric Evans 描述,我在新浪潮 DDD+SQRC+EventSourcing 模式聚合中看到了一些新鲜和好的想法。然而,CQRS 的主要思想对我来说是个大问题。我错过了什么吗?
domain-driven-design - 访问域对象中的会话
我们在我们的应用程序中使用事件溯源,并且严格需要跟踪对我们的许多对象发起更改的用户。目前我们有这样的代码
由于我们的大多数方法都是这样的,而且所有的方法都是这样调用的
我们正在考虑访问域对象内的 SessionContext。IE:
变成
我个人更喜欢后面的方法签名,因为它接缝更自然,另一方面,访问 Domain 对象内的 SessionContext 感觉有点混乱。
那么如何在 DDD/CQRS 应用程序中最好地处理这样的会话数据?是否可以访问域对象中的 SessionContext 或者我应该使用其他方法(如事件丰富)将此信息添加到从域发出的事件中?
domain-driven-design - CQRS/EventStore - 如果命令不应该失败,你如何管理一棵大树?
我读到 CQRS 中的命令被设计为不会失败,并且本质上应该是异步的。
就我而言,我有一棵树(想想 Windows 资源管理器),其中用户有代表视频内容位置的文件夹,每个子节点都是一个视频/媒体文件。多个用户都可以在树的同一分支上移动文件夹和文件(并上传新文件和创建新文件夹以及删除文件/文件夹)。
如果我忽略了命令的异步性质,我可以让第一个用户进行更改并在第二个用户提出异常,如果说用户将视频移动到的文件夹不再存在。现在第二个用户有责任刷新他的树的一部分,然后重新应用他的更改。
如果我的更改未被允许(即我尝试将视频文件移动到另一个文件夹并且另一个用户已删除该文件夹或将其移至其他位置),我将如何使用 CQRS 执行此操作?
design-patterns - 在 CQRS/ES 系统中存储命令有哪些优势?
我正在开发 CQRS/事件存储系统。目前,我使用的模式是命令同步。也就是说,在命令完成之前,用户界面不会将操作显示为已完成,并且会向用户显示成功/失败。在命令执行期间,所有生成的事件(例如,在聚合根 Y 上发生的动作 X)都存储在持久存储中。
我读过的所有关于 CQRS 的描述都实现了命令存储。我想知道在我的情况下是否需要这样做。
另一个注意事项 - 有很多长时间运行的命令类型操作,因此我将操作分解为一个生成事件的命令,然后这些事件依次发出更多命令。这些命令是幂等的,基于聚合根的状态。我不知道这会如何影响答案,但值得指出。