CQRS & Event Sourcing are good ideas, but putting yourself ON PURPOSE with eventual consistency is nuts.

Until your are in the facebook-big-data scaling challenging, you don't need the madness of lose ACID. You can get terabytes of data easily on a single server, and even partition by company, customer or similar that still allow to keep domain-level consistence.

Now, I put the events after my normal CRUD operations (ie: I emit CRUD + Save to event in a single transaction). Is super easy of operate and keep coding familiar and predictable

----

I think the ideal EE database engine must be like:

Have a log Table, and a index/subtables for each validation (ie: to check uniques, aggregates, counts, etc.)

So, if a have a customer related events, I have:

- Index on: code, name

- SubTable: code, name, isactive

all the other fields are not need for validation so are recovered from the log.

In ACID:

- POST Command

- Validate data with the index,

- Save to log

- Emit blocking events (events that need to be at the same time after the save)

- Commit

Eventual:

- Emit lazy events (events that not need ACID, like to fill external sources)