Currently an inconsistent revision that would cause an exception to be thrown, such as a precondition exception or an invariant violation, is rejected and the world remains unchanged.
This won't work well in practice, especially in a real time environment with concurrent updates; we can't have clients expect to literally stop the world (instance) while they work out why their latest revision attempt didn't work. This is going to be exacerbated by concurrent updates where a single client cannot reason about the sequence of revisions that lead up to the inconsistency.
What is proposed here is to record the revision and mark the item whose mutation caused the exception is being in an inconsistent state. Any item that were mutated are considered to be OK, and any items that might have been updated had the event run to completion are considered to be unaffected.
So queries have to be generalised to accommodate the notion of an inconsistent item,; perhaps this could be represented in much the same manner as a ghost - accessing a non-trivial method causes an explanatory exception to be thrown, and there is an API to check whether an object is inconsistent.
Correcting the inconsistent revision can either remove the inconsistency and update all relevant items, or could yield a new inconsistency, both cases need to be accommodated.
Currently an inconsistent revision that would cause an exception to be thrown, such as a precondition exception or an invariant violation, is rejected and the world remains unchanged.
This won't work well in practice, especially in a real time environment with concurrent updates; we can't have clients expect to literally stop the world (instance) while they work out why their latest revision attempt didn't work. This is going to be exacerbated by concurrent updates where a single client cannot reason about the sequence of revisions that lead up to the inconsistency.
What is proposed here is to record the revision and mark the item whose mutation caused the exception is being in an inconsistent state. Any item that were mutated are considered to be OK, and any items that might have been updated had the event run to completion are considered to be unaffected.
So queries have to be generalised to accommodate the notion of an inconsistent item,; perhaps this could be represented in much the same manner as a ghost - accessing a non-trivial method causes an explanatory exception to be thrown, and there is an API to check whether an object is inconsistent.
Correcting the inconsistent revision can either remove the inconsistency and update all relevant items, or could yield a new inconsistency, both cases need to be accommodated.