I think you may be mixing two different consistency concepts here. One is the consistency of the aggregate (will a state changing operation be operating on actual or obsolete data) and the other is consistency between the read and write models.
The conflict resolver you mentioned is meant to help you with the former but not the later. I’m not an expert in the subject and perhaps @Steven_van_Beelen and/or @allardbz will correct me here and/or provide more details but I’ll try to briefly explain the purpose of the conflict resolver to the best of my knowledge.
When one sends a command that contains
@TargetAggregateVersion to an aggregate, the expectation is that the command handler would update the state of the aggregate from what it was at that particular version. The version information is crucial if the command handler relies on calculations and/or reasoning that involves both the aggregate’s state (at given version) and the command’s payload.
Because of the async nature of command handling, chances are other commands may have changed the state of the aggregate in the time frame between when this client sent the command and the time command handler started processing it. Those changes may have been applied to the very same data the current command will modify (which means it should be rejected) or on totally unrelated part of the aggregate’s data (which means it can proceed). The conflict resolver you mentioned is meant to tell the command handler if there is a conflict or not.
For example in the open source project you linked to, the command handler uses a conflict resolver that basically says “Reject the command if any of the
MoneyReceivedEvent events have occurred since the version I expect (as they cause conflicts). Otherwise proceed”. A much simpler and perhaps easier to understand example is the framework’s ConflictResolutionIntegrationTest.
I hope that helps understand the role of the conflict resolver. As for the
My concern is about the eventual consistency with the CQRS pattern
I’m afraid I can’t help much with that. The way I understand it, eventual constancy is at the heart of CQRS. Obviously you can have various ways of marking and tracking data as it flows through different systems. That said, I don’t think you’ll ever be able to have the type of consistency RDBMS provide.