CODEWITHSUNDEEP
cqrsevent-sourcingaxon
howells699
howells699

Reputation: 148

Correct way of handling exceptions from aggregates after they have been deleted

After an aggregate has been deleted using the method markDeleted() , what is the correct way of handling a request using the same aggregate identifier?

The markDeleted() method marks and aggregate as deleted, when a create event is then attempted using the same aggregate identifier, an exception is thrown.

Is it just a case of a try/catch?

If I need to be more clear, let me know.

Thanks in advance,

P.S) Hi Allard! :)

Upvotes: 0

Views: 604

Answers (1)

Steven
Steven

Reputation: 7275

I'd suggest against reusing the Aggregate Identifier of a deleted Aggregate instance.

Axon can go two ways when you're doing stuff like this: 1. The old Aggregate Identifier is reused in a Command which will instantiate an Aggregate (I like to call them 'Constructor Command Handlers'). In that case an exception is thrown in the Event Storage Engine stating the given event already exists. 2. The old Aggregate Identifier is reused for a Command which performs some decision making. In other words, this Command will have the @TargetAggregateIdentifier annotation tied to the old Aggregate Identifier. In this scenario the Aggregate will be Event Sourced (assuming you're doing Event Sourcing), up to the Event which marks the Aggregate to 'deleted'. Then you'll get another exception in your face stating that this is incorrect behavior.

If you really need to reuse that Aggregate Identifier, you will have to remove the events for that old aggregate you have deleted; very likely not the thing you want to do.

As such it is better to use a UUID, which (almost) guarantees you of a unique aggregate identifier. That way you can safely mark aggregate as deleted and not be bothered with handling exceptions in this space.

P.S. I'll say hi to Allard for you.

Upvotes: 2

Related Questions