Hello all,
While looking at AxonFramework’s documentation I saw a reference to state-based aggregates (https://docs.axoniq.io/reference-guide/implementing-domain-logic/command-handling/state-stored-aggregates).
So, this got me thinking… for what use cases is it better to use one or another?
Thanks!
Armando
Hello Armando,
It is a very good question!. The short answer is: It depends 
The long answer is:
In general, it is a decision on should you use the Event sourcing pattern or not.
Event Sourcing mandates that the state change of the application isn’t explicitly stored in the database as the new state (overwriting the previous state) but as a series of events. This way you don’t lose any data/information by constantly overwriting it. Everything that happened in the system is stored. Information is far more valuable than the price of the storage these days, don’t throw it away!
There is a price: It is very nice to have all the history, but you have a responsibility to drag this history with you as your application evolves (events changed, aggregates changed, backward compatibility, …). Axon Framework helps a lot with Upcasting, Snapshotting, Serialization concepts so you do not have to implement this on your own. Axon Server on the other side is a message broker and event store, which gratefully simplifies the infrastructure.
One part of the DDD community shares the opinion that only Core subdomains/systems should utilize Event Sourcing, and that Supporting or Generic subdomains/systems could go without it. My honest opinion is that with Axon Framework and Axon Server you can event-source all of the subdomains/systems that your team is constructing in-house.
Best,
Ivan
I’m currently using state-based aggregates where I do not care about the event history being stored forever, and/or I only require the latest state of an aggregate.
It comes in handy in Axon because I can still use DDD to model my commands/events and my state-based aggregates have @CommandHandler/@EventHandler methods like normal.
Hello,
Thanks for your answers! It clarified some things. Some more questions come to mind though.
How does Axon handle the persistence of the aggregate in the database? So, let me elaborate a bit. When using an Event Sourced approach every time an EventSourcingHandler is executed the aggregate is updated. If you have snapshotting configured, after a certain amount of events processed, the aggregate is persisted in the snapshot table. If the service goes down 50 events after your last snapshot that is fine because when it’s restarted it picks the last snapshot and replays until your last event. So, all good here. However in this state-based approach the aggregate can be updated in both CommandHandlers and EventHandlers. So, is the aggregate persisted EVERY TIME after the execution of a CommandHandler and/or EventHandlers? Wouldn’t that add a lot of load to the database? Not only we would still have to persist events (expensive as it is this operation) but we would also have to store the aggregate in the database all the time. Now, if that is not the case and the aggregate is modified in memory and then persisted every now and then, how would it recover after a service crash?
On a related note, when using the state-based aggregates, it feels like storage of events stops being so important, so (depending on the system I guess) it would be possible to archive events or even delete them every now and then, or maybe not even persist them in a relational database and just use a messaging system to move them around? What’s a sensible approach when it comes to messaging in this scenario?
Thanks again,
Armando.