我有一个场景，当用户请求删除时，可能会根据某些逻辑将给定实体标记为软删除或硬删除。
从 DDD 范式处理这个问题，我看到了一些问题：- DDD 建议将 Repository 对象用于所有与持久性相关的东西，其中域层只定义了这样的 repo 接口（包含典型的方法，如存储、删除、查找）和包含实际执行。鉴于此，对于我的问题，决定是否进行软删除的逻辑属于域层，如何在域层中包含逻辑，以保证任何其他删除请求的安全性在实际调用 RepoImpl 上的删除点之前，层通过此逻辑进行引导，该删除点实际上从底层存储中删除了实体 ??。
即使我有一个具有类似方法的域服务void removeEntity(Entity ent)，我必须在我的 repo 接口上调用一个公共方法这一事实void remove(Entity ent)违背了目的，因为我不能强制执行removeEntity服务层的调用，而不是remove在 repo 上调用，并且 RepoImpl 需要有一个 remove 方法来实现删除一个实体。
建议的解决方案
==============
我有这个想法看起来很做作，假设 Repo 接口有一个抽象实现，它提供了一个 final public void remove(Entity ent)，抽象实现可以做这个逻辑来确定是否它是软删除还是硬删除。如果它是软删除，它实际上是对设置了适当标志的实体的更新，所以它调用，this.store(ent)否则它将实体包装在一个DeleteEvent类中
public class DeleteEvent<T>{
//parametrized for Entity
private T ent;
DeleteEvent(T ent){
this.entity = ent;
}
public T getEntity(){
return this.entity;
}
}
请注意非公共的包访问构造函数，该类的对象只能从域层内构造，因此 RepoImpl 上的另一个删除方法是void removeFromStore(DeleteEvent evt) RepoImpl 从该密封器/持有者获取实体并实现删除过程。
这虽然看起来可以工作是相当古怪/hacky，有没有更清洁的方法来实现同样的？