4 ms·

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

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 you to rewrite events into an entirely new store. [1] The Dark Side of Event Sourcing: Managing Data Conversion http://files.movereem.nl/2017saner-eventsourcing.pdf http://files.movereem.nl/2017saner-eventsourcing.pdf

karmajunkie 10y ago
Good link! Looking forward to reading that. I've been following your projects on Github for awhile, good work—I don't necessarily agree with all of the design choices but we've built on the eventstore at work and I'm going to be using it on another project in the near future.
- slashdotdash 10y ago
  Please do feedback your ideas to improve these open-source projects. I'd be interested to find out how you're using CQRS/ES in Elixir.
  - karmajunkie 10y ago
    We've got a channel (#eventsourcing) on the elixir slack—low volume but frequently interesting discussions, please feel free to join us there as well.
kiwidrew 10y ago
Thanks for the link to the research paper, it's a good read. Are you aware of any event sourcing frameworks/datastores that use one (or more) of these strategies to tackle the problem of schema evolution?
- wmfiv 10y ago
  Axon Framework is a very mature solution for ES on the JVM. http://www.axonframework.org/ http://www.axonframework.org/ Here's the section of their manual related to this. http://www.axonframework.org/docs/2.4/repositories-and-event-stores.html#event-upcasting http://www.axonframework.org/docs/2.4/repositories-and-event... Akka Persistence is the other JVM ES framework that I'm familiar with. it supports upcasting as well. http://doc.akka.io/docs/akka/2.4/java/persistence-schema-evolution.html http://doc.akka.io/docs/akka/2.4/java/persistence-schema-evo...
nobugs 10y ago
FWIW: IMO, we should separate CQRS and ES. CQRS is a Good Thing(tm); for a real-world example of it in work on a not-so-shabby system processing 10B+ transactions/year - see http://ithare.com/gradual-oltp-db-development-from-zero-to-10-billion-transactions-per-year-and-beyond/ http://ithare.com/gradual-oltp-db-development-from-zero-to-1... . ES, however, is more controversial. If speaking about "pure" ES (i.e. not having any mutable state, and reconstructing current state from input events all the time) - versioning and potential synchronization failures (and synchronized access is a prereq for event sourcing) will kill it very quickly (and I didn't even start speaking about performance, which is going to be a very serious challenge). OTOH, if understanding ES just as an ADDITION to classical mutable-state processing - it can be made very useful. Not only ES will serve as a perfect audit, the duplication of information (once in mutable state and once in input events) will allow such things as regression testing, and fixing data problems caused by bugs, within the DB. BTW - with this model, the latter can be done in a post-factum-fix manner and this, unlike "pure-ES" fixes, is not confusing to the readers who already got and stored previous state of the DB (with "pure" ES, after the fix, all the history can change, invalidating all the data which might have been stored by the third parties, and this is really crazy - imagine if your bank statements would change overnight; with a "ES+mutable" model, bugs still can be identified, and effects of the bugs can be found too - and then a separate correcting transaction can be issued against the DB, which is a much better match to a vast majority of existing business processes). Hope it makes sense :-) (it is admittedly very sketchy, but forum is not a good place to elaborate further)

karmajunkie 10y ago

Good link! Looking forward to reading that. I've been following your projects on Github for awhile, good work—I don't necessarily agree with all of the design choices but we've built on the eventstore at work and I'm going to be using it on another project in the near future.

slashdotdash 10y ago
Please do feedback your ideas to improve these open-source projects. I'd be interested to find out how you're using CQRS/ES in Elixir.
- karmajunkie 10y ago
  We've got a channel (#eventsourcing) on the elixir slack—low volume but frequently interesting discussions, please feel free to join us there as well.

kiwidrew 10y ago

Thanks for the link to the research paper, it's a good read. Are you aware of any event sourcing frameworks/datastores that use one (or more) of these strategies to tackle the problem of schema evolution?

wmfiv 10y ago
Axon Framework is a very mature solution for ES on the JVM. http://www.axonframework.org/ http://www.axonframework.org/ Here's the section of their manual related to this. http://www.axonframework.org/docs/2.4/repositories-and-event-stores.html#event-upcasting http://www.axonframework.org/docs/2.4/repositories-and-event... Akka Persistence is the other JVM ES framework that I'm familiar with. it supports upcasting as well. http://doc.akka.io/docs/akka/2.4/java/persistence-schema-evolution.html http://doc.akka.io/docs/akka/2.4/java/persistence-schema-evo...

nobugs 10y ago

FWIW: IMO, we should separate CQRS and ES. CQRS is a Good Thing(tm); for a real-world example of it in work on a not-so-shabby system processing 10B+ transactions/year - see http://ithare.com/gradual-oltp-db-development-from-zero-to-10-billion-transactions-per-year-and-beyond/ http://ithare.com/gradual-oltp-db-development-from-zero-to-1... . ES, however, is more controversial. If speaking about "pure" ES (i.e. not having any mutable state, and reconstructing current state from input events all the time) - versioning and potential synchronization failures (and synchronized access is a prereq for event sourcing) will kill it very quickly (and I didn't even start speaking about performance, which is going to be a very serious challenge). OTOH, if understanding ES just as an ADDITION to classical mutable-state processing - it can be made very useful. Not only ES will serve as a perfect audit, the duplication of information (once in mutable state and once in input events) will allow such things as regression testing, and fixing data problems caused by bugs, within the DB. BTW - with this model, the latter can be done in a post-factum-fix manner and this, unlike "pure-ES" fixes, is not confusing to the readers who already got and stored previous state of the DB (with "pure" ES, after the fix, all the history can change, invalidating all the data which might have been stored by the third parties, and this is really crazy - imagine if your bank statements would change overnight; with a "ES+mutable" model, bugs still can be identified, and effects of the bugs can be found too - and then a separate correcting transaction can be issued against the DB, which is a much better match to a vast majority of existing business processes). Hope it makes sense :-) (it is admittedly very sketchy, but forum is not a good place to elaborate further)