The distinction between the way Event Sourced and State Stored Aggregates is not clear enough

[rhubarb]

It's clear that there IS a distinction, and it is also clear how to code each one, however, it was not clear to me:

• that an Aggregate instance (i.e an instance of the Aggregate java class) is dereferenced (dropped/garbage-collected) at the end of each command, and reconstructed from events at the start of the next command (when in EventSourced mode)

• that I can still write replay code to re-hydrate my projections, even if using State-stored (non-ES) projections

• that the "event sourcing" of an Aggregate is quite distinct from event sourcing of the query model (projections) in several ways:

  1. Aggregate ES is automatic (repository is created implicitly and updated automatically) vs Projection ES is "manual" (repository is created in my projection implementation and entities added, updated by my code)
  2. Aggregate ES gets "replayed" automatically on every command vs Projection replay requires specific API to be invoked.

• what the PROs, CONs of Aggregate ES vs State-Stored Aggregate are: Aggregate ES seems to "cost more" in performance, with no real benefit: I can still source and replay for projections, so why the extra event store for my aggregates? As far as I can tell, the only benefit is that it forces the good practice of keeping state change code in event-handlers and out of command handlers, so that events remain the proper source of truth of the state of the aggregate

[smcvb]

Thanks for providing this issue description, @rhubarb. As time progresses for Axon's 10+ year existence, we notice more people endeavoring this route without the complete theoretical background. Hence, our reference guide requires adjustments to tailor towards a newer group, in essence.

Having said that, I'd like to rule out some predicaments in your description already before effort on a pull request for this issue starts:

that the "event sourcing" of an Aggregate is quite distinct from event sourcing of the query model (projections) in several ways

Note that the query side of your application is not Event Sourcing. A Query Model instance is not "sourced based on the events it has published." Basically, because it does not publish anything, to begin with. It simply streams events from a streamable source.

Ergo, from the query side's perspective, we're dealing with Event Streaming instead of Event Sourcing. I believe this blog from Oskar Dudyz does a great job explaining this difference.

...so why the extra event store for my aggregates...

To be honest, I don't see how extra storage is involved with this approach. Maybe you could state the Event Store contains more, but your only hard requirement would be the Event Store itself when it comes to storage solutions. When you're going for a State-Stored solution for the aggregate, you'd instead need:

1. A storage location for the aggregate
2. A (possibly persistent) location to store events
3. A storage solution for your projections

When going for Event Sourcing, you'd effectively eliminate requirement one. Furthermore, it ensures you that the business validation (performed in the aggregate) is always based on the model's most recent state.

---

With that said, I still agree that the other pointers you address have justice within the Reference Guide, one way or another. In the meantime, I hope the above provides some insights into this too. And, if there are ever any questions, you should feel free to reach out too. :-)

Thanks again for drafting this issue, @rhubarb. Hope to chat with you in the future still.