为了支持离线客户端，我想评估如何将多版本并发控制与 CQRS-DDD 系统相适应。
从 CouchDB 学习，我很想为每个实体提供一个版本字段。但是还有其他版本的并发算法，例如 vector clocks 。这让我觉得也许我不应该为每个实体和/或事件公开这个版本概念。
不幸的是，我见过的大多数实现都是基于软件在单个服务器上运行的假设，其中事件的时间戳来自一个可靠的来源。但是，如果某些事件是远程且离线生成的，则本地客户端时钟偏移存在问题。在这种情况下，正常的时间戳似乎不是订购事件的可靠来源。
这是否迫使我评估某种形式的 MVCC解决方案不基于时间戳？
离线 CQRS 客户端必须评估哪些实现细节才能将延迟的事件链与中央服务器同步？
有什么好的开源例子吗？
我的 DDD 实体和/或 CQRS 查询 DTO 是否应该提供版本参数？
最佳答案
我管理一个版本号，它对我来说效果很好。版本号的好处是，在处理并发冲突时，您可以使代码非常明确。我的方法是确保我的 DTO 都具有与其关联的聚合的版本号。当我发送命令时，它具有客户端上看到的当前版本。该数字可能与聚合的实际版本同步，也可能不同步，即。客户端已离线。在事件被持久化之前，我检查版本号是否是我期望的版本号，如果不是，我会检查前面的事件以查看其中是否存在实际冲突。只有这样，如果他们这样做了，我才会提出异常(exception)。这本质上是一种非常细粒度的乐观并发形式。如果您感兴趣，我在我的博客上写了更多详细信息，包括一些代码示例:http://danielwhittaker.me/2014/09/29/handling-concurrency-issues-cqrs-event-sourced-system/
希望对您有所帮助。
关于domain-driven-design - 多版本并发控制以及CQRS和DDD，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/21486891/