Question

How does CQRS handle post-conditions on immediately consistent models? I realise something like this is irrelevant on an eventually consistent system w/ event sourcing etc. But if I just wanted to apply vanilla CQRS to a simple interface, how would I write my post-conditions? Is the idea of CQRS to always assume eventual consistency?

CRUD:

IDictionary
{
   void Set(string key, object value); // Ensures: Get(key) == value
   object Get(string key);
}

CQRS:

IDictionaryQueries
{
   object Get(string key);
}

IDictionaryCommands
{
   void Set(string key, object value); // Ensures: ???
}
Was it helpful?

Solution

Think about it in therms of transactional behaviour and boundaries. In immediately consistent models the Set and Get are going to be executed in the same transaction. The "transaction" is going to ensure that the actual storage behind the two interfaces is going to always be consistent. This is your guarantee that after calling the Set method, the Get method is going to return the expected value. This guarantee is kept as long as the implementation does not introduce a decoupling mechanism, like messaging.

With eventual consistency the two operations are performed in different transactions and the only guarantee is that eventually the Get is going to return the expected value.

Now in therms of code-contracts, and i must say that i'm not very familiar with them, i does kind of defeat the purpose of CQRS to have a post-condition ( on a Command operation ) that relies on a Query like operation. Maybe your post-condition should not be expressed in therms of the Get operation, but more like "The Command was executed successful". This would be your post-condition at interface level. At implementation level where you will most probably have the same class implementing both interfaces you could express the post condition based on the Get operation.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top