Hi,
in AF5 the AggregateLifecycle.markDeleted() has been removed and maybe as a consequence Axon does not throw an AggregateDeletedException anymore if trying to send a command for a deleted aggregate/entity.
I guess this is intentional, but it may lead to some rework when migrating to AF5. With AF5 it is possible to send a delete command to the same aggregate/entity multiple times. With AF4 you got an AggregateDeletedException. This could produce unwanted events, if you do not explicitly handle the deleted state on your own in the aggregate. With AF4 we could rely on this exception as a guard.
I thought we added a migration path for this, but that’s still stuck in a “we should” instead of a “it’s present” stage.
In absence of that page, I’ll give a bit of background.
The AggregateLifecycle#markDeleted operation was essentially nothing more than a bit of state that Axon Framework maintained and validated. Throughout the years, we are aware users used this, but we have received equal number of requests why we support this.
It’s a choice of the user what state would mark an aggregate/entity as deleted. Equally so, it’s a choice how to react to that deletion, per chance on a per command-basis.
Hence, given that it is essentially a domain-specific choice, thus easily implemented by the user themselves, we decided against reintroducing the method. On top of that, our hard requirement to drop any usages of thread locals and aggregate-specifics make it tough to find an equivalent spot to carry the method in.
So long story short, if you’re using AggregateLifecycle#markDeleted, we recommend that you (1) add a custom boolean to your entity/aggregate that states it’s deleted and (2) validate that state whenever needed. Starting AF5.2.0, you will be able to use an @MessageHandlerInterceptor again which does the validation for you.