given a simple ToDo list application. I wouldn’t need any information in the aggregate except for the id, as each command should result in an event no matter what the current status of the ToDo-Item is. The status and content of a ToDo-Item is only needed on the read side. Should more complex aggregates be minimized like that, such that i only have those attributes in the aggregate that are used to determine whether an event should be apllied or not?
If thats the case is it good practice or does it even have performance benefits as applying the events to get the current status of the aggregate becomes faster?
sounds interesting. One thing that come into my mind:
Events emitted from Aggregates get connected to them.
This might make no difference for id-onlyaggregates,
but it is worth diggin into that code.
I remember "AggregateLifecycle" in that context.
Emitting events is possible since one of the last axon updates.
If there needs to be a validation in future,
it could be more difficult to introduce an aggregate afterwards.
Thanks for your answer. But i think i didn't get what you mean. As far as i know the described case is no problem with ES. if i need an attribute later i just modify my Aggregate and add that attribute and an event handler as the Aggregate is rebuild from the events each time it is called. When i need an attribute in the future i just have to start sourcing it from the events as there is no Aggregate entity at all.
AFAIKS, you won’t need the attributes in the aggregate, if you don’t do anything with them and if you use event sourcing (and not state stored entities).
I went one step further and tried out, what happens, when i delete the @EventSourcingHandler method (since it does nothing if there is no attribute). This also seems to work fine (as far as my little showcase revealed).
To carry this idea another step further, one might ask, if it is even possible to delete the aggregate, since it only sends events for commands directly. This was the thing i had in mind. Regarding this, i’ve found the following discussion: AxonFramework/issues/510
This seems to be a more experimental approach, where i’m not sure, how easy it would be, to introduce the aggregate later,
when the model evolves.
This might be a thing, if all aggregates become “stupid” command-to-event-converters, which would lead to an anemic model.
On the other hand, it is extremely rare, that there is no logic at all when dealing with (represented/real) state.