2

为了支持离线客户端，我想评估如何将多版本并发控制与 CQRS-DDD 系统相匹配。

向 CouchDB 学习，我很想为每个实体提供一个版本字段。但是还有其他版本的并发算法，例如矢量时钟。这让我想，也许我不应该为每个实体和/或事件公开这个版本概念。

不幸的是，我看到的大多数实现都是基于软件运行在单个服务器上的假设，其中事件的时间戳来自一个可靠的来源。但是，如果某些事件是远程和离线生成的，则本地客户端时钟偏移存在问题。在这种情况下，正常的时间戳似乎不是订购我的事件的可靠来源。

  1. 这是否迫使我评估某种形式的不基于时间戳的MVCC解决方案？

  2. 离线 CQRS 客户端必须评估哪些实现细节才能将延迟的事件链与中央服务器同步？

  3. 有什么好的开源例子吗？

  4. 我的 DDD 实体和/或 CQRS 查询 DTO 是否应该提供版本参数？

4

3 回答 3

3

我管理一个版本号，它对我来说效果很好。版本号的好处是您可以在处理并发冲突时使代码非常明确。我的方法是确保我的 DTO 都有与之关联的聚合的版本号。当我发送命令时，它具有客户端上看到的当前版本。这个数字可能与聚合的实际版本同步，也可能不同步，即。客户端已离线。在事件持续存在之前，我检查版本号是否是我预期的版本号，如果不是，我会检查前面的事件以查看它们中的任何一个实际上是否存在冲突。只有这样，如果他们这样做，我才会提出异常。这本质上是一种非常细粒度的乐观并发。如果你有兴趣我'http://danielwhittaker.me/2014/09/29/handling-concurrency-issues-cqrs-event-sourced-system/

我希望这会有所帮助。

于 2014-09-29T09:29:23.177 回答
0

我想您应该重新考虑您的域，在其自己的有界上下文中分离远程客户端逻辑，并使用已知的 DDD 原则将其与其他 BC 集成以实现 BC 互操作。

于 2014-02-03T14:26:19.083 回答
0

我建议你看看 Greg 关于这个主题的演讲。它可能有您正在寻找的答案https://skillsmatter.com/skillscasts/1980-cqrs-not-just-for-server-systems

于 2014-01-31T21:08:21.260 回答