【发布时间】：2012-07-25 06:05:52
【问题描述】：
我有一个场景，当用户请求删除时，可能会根据某些逻辑将给定实体标记为软删除或硬删除。
从 DDD 范式处理这个问题，我看到了一些问题：- DDD 建议将 Repository 对象用于所有与持久性相关的东西，其中域层只定义了这样的 repo 接口（包含典型的方法，如存储、删除、查找）和包含实际执行。鉴于此，对于我的问题，决定是否进行软删除的逻辑属于域层，如何在域层中包含逻辑，以保证任何其他删除请求的安全性在实际调用 RepoImpl 上的删除点之前，层通过此逻辑进行引导，该删除点实际上从底层存储中删除了实体 ??。
即使我有一个域服务具有像 void removeEntity(Entity ent) 这样的方法，我必须在我的 repo 接口上有一个名为 void remove(Entity ent) 的公共方法这一事实违背了目的，因为我无法强制服务层的 removeEntity 是在 repo 上总是被调用而不是 remove 和 RepoImpl 需要有一个 remove 方法来实现实体的删除。
建议的解决方案
==============
我有这个看起来相当做作的想法，假设 Repo 接口有一个抽象实现，它提供了一个最终的 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上的另一个remove方法是void removeFromStore(DeleteEvent evt)RepoImpl从这个sealer/holder中获取实体并实现removal过程。
虽然看起来 can work 相当古怪/hacky，但有没有更清洁的方法来实现同样的效果？？
【问题讨论】：
标签： domain-driven-design ddd-repositories