I don’t have the final say in this approach you’re suggesting, that’s something we’d have to discuss with the team here.
But to give you my personal point of view: I don’t think if we’d add an issue for that, that we’d put it high on the backlog.
Nonetheless you’re free to suggest such an implementation by opening up an issue on our Github page.
Or even better, provide a solution by sending in a Pull Request.
To ‘not bloat’ your event store you could also think of implementing your own off loading strategy.
I’m saying off loading on purpose, as I still don’t think removal is the best approach to take if you want to do Event Sourcing.
Hope this give you some insights and I guess Allard will share his opinion as well once he’s got the time for it.
Ow and ‘Null Title’, I suggest against reusing the aggregate identifier of an aggregate you’ve marked deleted.
Can’t say I’ve tried this stuff, but I can only imagine the repositories in Axon wont like that.
When Event Sourcing an Aggregate, the EventStore queries all the events for that aggregate based on the aggregate identifier.
And as pointed out, it’s ‘marked deleted’, not actually deleted.
Hence if you’d introduce another aggregate with the same aggregate identifier, you’d have more events when Event Sourcing then you’d bargained for.
I even think Axon will complain, telling you that you cannot introduce a second aggregate with the given aggregate identifier, since it already exists.