多版本并发控制和CQRS和DDD

Question

为了支持离线客户端，我想评估如何使用CQRS-DDD系统适应多版本并发控制。

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

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

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

2. 离线CQRS客户端评估哪些实施细节以使延迟的事件链与中央服务器同步？

3. 有没有好的开源示例？

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

Answer 1

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

我希望有所帮助。

Answer 2

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

Answer 3

我想你应该重新考虑你的域名，在自己的有界环境中分离远程客户端逻辑，并使用已知的DDD for BC互操作原则将其与其他BC集成。