3 ms·
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
by UK-AL 10y ago
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 10y agoIf 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.
- deleted 10y ago[deleted]
- UK-AL 10y agoCQRS by itself does not imply using ddd or es.
- karmajunkie 10y agoYeah, 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 10y agoDino Esposito describes an "historical" crud System in a series in msdn magazine https://msdn.microsoft.com/magazine/mt703431 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 10y agoHaven'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...