Soft Deletion in DDD

I have a scenario in which a given object can be marked for soft deletion or hard deletion based on some logic when the user requests deletion.

 Approaching this problem from the DDD paradigm, I see some problems: - DDD suggests using the repository object for all materials related to preservation, where the domain layer simply defines such a repo interface (containing typical methods such as preservation, deletion, search) and level infrastructure containing the actual implementation. Given that for my problem here, then the logic that decides whether to perform soft deletion or not belongs to the domain layer, how can I contain the logic in the domain layer so that the security that any deletion request by any other layer goes through this logic before moving to the point of the actual delete call on RepoImpl, which actually deletes the object from the main storage.

  Even if I have a domain service that has a method such as void removeEntity(Entity ent)the fact that I have to have an open method on my repo interface called void remove(Entity ent), the target wins, because I cannot ensure that removeEntitythe service level for the call is always instead of removeon repo , and RepoImpl must have a deletion method to ensure that the deletion of the object is implemented.

Proposed Solution
==============
  I have this idea that looks rather far-fetched, let's say the Repo interface has an abstract implementation that provides the finalpublic void remove(Entity ent)An abstract implementation can do this logic to determine if its soft or hard deletion. If its soft deletion is actually an update of the object with the corresponding flags, so it calls this.store(ent), otherwise it transfers the entity to the classDeleteEvent

 public class DeleteEvent<T>{
   //parametrized for Entity
  private T ent;
   DeleteEvent(T ent){
     this.entity = ent;   
}

 public T getEntity(){
   return this.entity; 
}
}

Pay attention to the non-public constructor of access to the package, objects for this class can only be created from the domain level, therefore another removal method on RepoImpl void removeFromStore(DeleteEvent evt)RepoImpl receives an entity from this sealant / holder and implements the removal process.
This, although it seems, can work quite bizarre / hacked, is there a cleaner way to achieve the same?