Well, normally one would make one command = one transaction. And given the nature of the event store, for transactions, we could use optimistic locking. This will mean events that are generated on an aggregate root that has already been versioned up (by another command), will have to throw a concurrency exception. The domain might actually still make something of this, because the intent of the action is not lost.

Greg suggests keeping the read database in the tranaction scope too, until this gets too bothersome. This will ensure consistency of the data you’re reading, of course. When this puts too much burden on the transactions (because of scaling up the number of db’s, for instance), you can always retract the transaction boundary to only include the event store. Your read db will then only be eventually consistent. Which in the majority of cases is enough.

Thanks for this clear, well-written article!

I’m jus wondering: what about locking and transactions in the circular architecture?