Building a CQRS/ES web application in Elixir using Phoenix

Post by karmajunkie » Fri, Jan 06, 2017, 10:19 PM UTC

UK-AL wrote: post #18

eric_b wrote: post #12

Earlier quoted context omitted.

I detailed some of the problems I saw in another thread, but one other thing that gets challenging is the CQRS side (if you choose to keep everything async). For example, say you fire an "address change" event. That gets sent to the event store for eventual projection in to a medium you can actually query from (realtime querying of the event store itself is the road to very bad places, I promise). So now your event i…

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.

Post by [deleted] » Fri, Jan 06, 2017, 10:23 PM UTC

karmajunkie wrote: post #22

UK-AL wrote: post #18

Earlier quoted context omitted.

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.

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.

Post by karmajunkie » Fri, Jan 06, 2017, 10:27 PM UTC

slashdotdash wrote: post #21

eric_b wrote: post #6

I have worked on, or cleaned up, 4 different CQRS/ES projects. They have all failed. Each time the people leading the project and championing the architecture were smart, capable, technically adept folks, but they couldn't make it work. There's more than one flavor of this particular arch, but Event Sourcing in general is simply not very useful for most projects. I'm sure there are use cases where it shines, but I ha…

I'm the author of this article. It sounds like you have some valuable, real-world experience with CQRS/ES. I'd love to read more about the difficulties you've faced, and overcome. For migration of immutable events, there's a good research paper[1] that outlines five strategies available: multiple versions; upcasting; lazy transformation; in-place transformation; copy and transformation. The last approach even allows…

Post by karmajunkie » Fri, Jan 06, 2017, 10:32 PM UTC

UK-AL wrote: post #25

karmajunkie wrote: post #22

Earlier quoted context omitted.

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.

CQRS by itself does not imply using ddd or es.

Post by slashdotdash » Fri, Jan 06, 2017, 10:36 PM UTC

arcbyte wrote: post #2

> CQRS library You missed the whole point of CQRS