Very impressive evolution and definitely seems like a legit solution for this problem domain.
Later some of us were arguing about if each transaction record contains only the delta, or it contains the complete transitioned state of the entity. In other words, let's say I update my User profile, and so there are 25 state transitions (one for every field edit). When I retrieve it, do I have to play all 25 transitions to hydrate my User, or is the complete state persisted in the last one, so I can only retrieve that to hydrate the User?
PS: I tweeted this at you too, but hard question to ask in 140 characters :-) https://twitter.com/jeremiahsmall/status/789600023948308480
In a naïve event-sourced system, the aggregate is reconstructed from all deltas in its history. This is usually fine for most scenarios, since aggregate logic is only called for write operations (read/write separation in CQRS - the aggregate is your write model).
This is usually fine, since most aggregates will have a small amount of events (
Previous comment came through only in half. Here's another attempt:
Hey Jeremiah,
In a naïve event-sourced system, the aggregate is reconstructed from all deltas in its history. This is usually fine for most scenarios, since aggregate logic is only called for write operations read/write separation in CQRS - the aggregate is your write model.
This is usually fine, since most aggregates will have a small amount of events, such as 10, 100, 1000.
Should you have edge-cases where thousands or millions of events are loaded per single aggregate, then you can cache the state of the aggregate up to the last replayed events. This is possible due to the immutable/append-only nature of the event stream, which allows you to cache any generated state forever, as long as the replay-code is the same.
Also, please avoid using the term "delta" when referring to event-sourcing. While it is technically correct, most of the advantages from ES come from the fact that we transition from persistence of data to actual domain events, which carry much more meaning than just a delta.
Great talk, nice and in-depth - I think maybe some info about state snapshots (as discussed in above comments) would be nice to include for next time, but otherwise nice, thanks :)
I've been interested in event sourcing (from a "people are talking about it, so I want to see what it's all about" perspective) for a while now, and it was great to see a practical example of it in action that I could easily wrap my head around. This talk gave me enough background information and reference material to play around with it on my own.
The speaker is extremely knowledgeable about this topic and other relevant topics that tie in to event sourcing, so this talk is bound to end with a good Q&A session if the crowd is large enough.
Even if you don't have a use case for it now (or do, but it wouldn't be practical to switch it over), you should still attend this talk in order to learn what it's all about so that you can be able to decide to use it or not when the opportunity arises. Fantastic talk!
Comments
Comments are closed.
Very impressive evolution and definitely seems like a legit solution for this problem domain.
Later some of us were arguing about if each transaction record contains only the delta, or it contains the complete transitioned state of the entity. In other words, let's say I update my User profile, and so there are 25 state transitions (one for every field edit). When I retrieve it, do I have to play all 25 transitions to hydrate my User, or is the complete state persisted in the last one, so I can only retrieve that to hydrate the User?
PS: I tweeted this at you too, but hard question to ask in 140 characters :-) https://twitter.com/jeremiahsmall/status/789600023948308480
Hey Jeremiah,
In a naïve event-sourced system, the aggregate is reconstructed from all deltas in its history. This is usually fine for most scenarios, since aggregate logic is only called for write operations (read/write separation in CQRS - the aggregate is your write model).
This is usually fine, since most aggregates will have a small amount of events (
Previous comment came through only in half. Here's another attempt:
Hey Jeremiah,
In a naïve event-sourced system, the aggregate is reconstructed from all deltas in its history. This is usually fine for most scenarios, since aggregate logic is only called for write operations read/write separation in CQRS - the aggregate is your write model.
This is usually fine, since most aggregates will have a small amount of events, such as 10, 100, 1000.
Should you have edge-cases where thousands or millions of events are loaded per single aggregate, then you can cache the state of the aggregate up to the last replayed events. This is possible due to the immutable/append-only nature of the event stream, which allows you to cache any generated state forever, as long as the replay-code is the same.
Also, please avoid using the term "delta" when referring to event-sourcing. While it is technically correct, most of the advantages from ES come from the fact that we transition from persistence of data to actual domain events, which carry much more meaning than just a delta.
Great talk, nice and in-depth - I think maybe some info about state snapshots (as discussed in above comments) would be nice to include for next time, but otherwise nice, thanks :)
I've been interested in event sourcing (from a "people are talking about it, so I want to see what it's all about" perspective) for a while now, and it was great to see a practical example of it in action that I could easily wrap my head around. This talk gave me enough background information and reference material to play around with it on my own.
The speaker is extremely knowledgeable about this topic and other relevant topics that tie in to event sourcing, so this talk is bound to end with a good Q&A session if the crowd is large enough.
Even if you don't have a use case for it now (or do, but it wouldn't be practical to switch it over), you should still attend this talk in order to learn what it's all about so that you can be able to decide to use it or not when the opportunity arises. Fantastic talk!
This talk covered material I wasn't familiar with and that was a welcome change. Well presented and good source material.