我这里有一个给定的实体可以被标记为删除软或硬的基础上删除一些逻辑，当用户请求删除的场景。
走近从DDD模式这个问题，我看到了一些问题： - DDD建议使用Repository对象的所有持久性相关的东西，其中域层仅仅定义（含像商店典型的方法，删除，查找）这样的回购接口和包含的基础建设层实际执行。 鉴于此，我的问题在这里的话，那决定是否做了软删除或不属于领域层的逻辑，怎么可能包含在领域层的逻辑以这样的方式在安全性，通过任何其他任何删除请求层通过该逻辑来的实际调用上RepoImpl实际去除底层存储实体??一个删除点之前提供的。
即使我有有等的方法域服务void removeEntity(Entity ent) ，事实上，我也有我的呼吁回购界面上的公共方法void remove(Entity ent)失败的目的，因为我不能强制执行removeEntity服务层是被称为始终，而不是remove在回购和RepoImpl需要有一个remove方法给实现去除一个实体的。
建议的解决方案
==============
我有这个想法，看起来相当做作，假设回购接口有有提供最终的抽象实现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从该密封器/保持器获取实体，并实现了去除处理。
这虽然看起来可以工作是相当古怪/哈克，是有一个更清洁的方式来达到同样的？
