of course, technically speaking it is an anti-pattern. Even if we have a separate class for each event type resulting from a command type, that represent a distinguished business logic action. But all these event classes have that key-value-store-like contents. We will have approx. 100 event classes just for one of the aggregates, which has around 100 different attributes altogether. You may think this as such is a bad design, but the domain of this system is German law… A world away from a customer-order example I am quite sure, if we define normal event classes, each of them having in essence a subset of those 100 attributes, we may need often to write upcasters as bugs and extensions in the command handlers are found and, as a consequence, event types will get changed in the future… Still, you are right, we are still considering to change to normal events…
Serialization was not my point, we fully understand the approach of AxonIQ GDPR. Besides the final deletion we have also the requirement of anonymisation, which AxonIQ GDPR also would solve.
Another issue is of course is the cost AxonIQ GDPR.
But that was not my question, actually ;-( The question still is the deletion of events in Axon. Could you pls say if is safe to do it from technical perspective with Axon?