Where does AggregateLifecycle.markDeleted() get called from, and why not from the @CommandHandler that handles the delete request?

AggregateLifecycle.markDeleted() is called from inside the @EventSourcingHandler method that reacts to the deletion event (for example, on(CustomerDeletedEvent event)), not from the @CommandHandler that initially handles the delete command. This follows the same command/event separation used everywhere else in an aggregate: the command handler's only job is to decide whether the deletion is allowed and, if so, apply a deletion event; the actual state change — including marking the instance as finished — belongs in the event sourcing handler, since that's the method responsible for turning an already-decided event into an actual change on the aggregate. Calling markDeleted() from the command handler directly would bypass the pattern that keeps every real state change flowing through event sourcing handlers, which is exactly the pattern that makes an aggregate's state reproducible purely by replaying its events.