[UK-AL]

The address thing is normally solved by the fact that you organise your commands by things that should only logically change togther. So a conflict messages won't revert irrelevant fields back to their old ones.

So your commands should not be

UpdateCustomer

They should be

UpdateCustomerAddress UpdateCustomerEmail

Etc

For the address, just take the last one. All the business logic I can think makes this ok.

[karmajunkie]

If your events contain the words "Create", "Update", or "Delete", or any synonym thereof, you're modeling CRUD with events and life is always going to be more complicated than it has to be for you. The names of events are data too—make them representative of the domain.

CustomerMoved(fromAddress, toAddress) is a domain event.

[UK-AL]

CQRS by itself does not imply using ddd or es.

[karmajunkie]

Yeah, fair enough, but if you're not using ES then the names of messages don't matter a whole lot because you don't have to live with them forever.

(Edit: ok, they matter some, in the way names of variables and apis matter.)

[Haldir]

Dino Esposito describes an "historical" crud System in a series in msdn magazine https://msdn.microsoft.com/magazine/mt703431 This is basically ES with crud. Not saying ES with crud is the best example, but for data which requires Audit Trail logic it actually works fairly well.

[karmajunkie]

Haven't read that article, but will check it out, thanks for the link.

My issue with audit logs in crud systems is that they're almost always at the row level, which is almost useless when you're trying to make sense of the audit log. An audit log of "operations"—i.e. command log—is far more useful, and trivial to implement when CQRS is used. I'm guessing that's what this article details...