ZendCon 2016
18 - 21 Oct 2016 at Hard Rock Hotel & Casino

Nice talk. Learnt some stuff! Thanks.

Good keynote, but there wasn't much info on how to relate this stuff back to the PHP world. Possibly because of the fact, demonstrably, the speaker doesn't really use PHP, and at one point (can't remember exactly what was said) treats it with a little contempt, which is a shame. Nevertheless, the talk was full of good advice, but it's kinda rubbish that we still need to be told this stuff. This talk is sadly a requirement, but it shouldn't be.

Overran a little, but that was fine as got extra discussion and insight (and no more talks after). The talk itself was great, learnt a few things, especially about the SAPIs (I had a vague understanding, but now much clearer). Thanks!

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.

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 (

Many thanks for attending the talk, please rate it.
For ideas or constructive discussion please contact me at <[email protected]>.

Thanks for attending the session, please rate it as well.
For any ideas or to discuss more about what presented, please contact me at <[email protected]>.

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

Good job. Maybe too many special cases in your examples (such as the Apigility user id), but on the other hand, that does demonstrate that unusual edge cases usually have a solution.

One of the best presentations I've been to during Zendcon. You completed the thinking round Zend Expressive for me. Finally I can move to Zend Expressive and quit building simpler websites with zf1 that I've been doing for 10 years.
Looking forward to seeing the code from the presentation.
I've checked out your website a few times so can really recommend that too for others too.
http://www.masterzendframework.com/