ユーザーが削除を要求したときに、論理に基づいて特定のエンティティが論理的な削除または完全な削除の対象としてマークされるシナリオがあります。
DDDパラダイムからこの問題にアプローチすると、いくつかの問題が見られます:-DDDは、ドメインレイヤーがそのようなレポインターフェース(ストア、削除、検索などの典型的なメソッドを含む)を定義するだけのすべての永続性関連のものにリポジトリオブジェクトを使用することを提案します。実際の実装。ここでの私の問題について、論理的な削除を行うかどうかを決定するロジックがドメイン層に属していることを考えると、ドメイン層にロジックを含めるにはどうすればよいでしょうか。層は、実際に基になるストアからエンティティを削除する RepoImpl で削除を実際に呼び出すポイントに到達する前に、このロジックを介してチャネル化されます??.
次のようなメソッドを持つドメイン サービスがある場合でも、void removeEntity(Entity ent)、レポインターフェイスにパブリックメソッドが呼び出される必要があるという事実は、目的を無効にします。これは、レポの代わりにサービスレイヤーを常に呼び出すことをvoid remove(Entity ent)強制できず、RepoImpl に remove メソッドを実装する必要があるためです。エンティティの削除。
提案された解決策==============
私はかなり不自然に見えるこの考えを持っています.Repoインターフェースに final を提供する抽象実装があるとしましょう.抽象実装はこのロジックを実行して、そのソフトまたはハード削除。ソフト削除の場合、実際には適切なフラグが設定されたエンティティの更新であるため、それ以外の場合はエンティティをクラスにラップしますremoveEntityremove
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 のもう 1 つの削除メソッドは、RepoImpl がvoid removeFromStore(DeleteEvent evt) このシーラー/ホルダーからエンティティを取得し、削除プロセスを実装することです。
これは機能するように見えますが、かなり風変わり/ハッキーですが、同じことを達成するためのよりクリーンな方法はありますか??