soft delete in DDD

Question

J'ai un scénario dans lequel une entité donnée peut être marquée pour une suppression logicielle ou une suppression matérielle selon une certaine logique lorsqu'un utilisateur demande une suppression. Je vois quelques problèmes: - DDD propose l'utilisation de l'objet Repository pour tous les objets liés à la persistance où la couche domaine définit juste une telle interface repo (contenant des méthodes typiques comme store, remove, find) et couche d'infrastructure contenant l'implémentation réelle. Étant donné que, pour mon problème ici alors, la logique qui décide de faire une suppression de domaine soft ou non appartient, comment est-il possible de contenir la logique dans la couche de domaine de telle sorte que la suppression de toute autre demande La couche est canalisée à travers cette logique avant d'arriver au point d'appeler réellement une suppression sur RepoImpl qui supprime réellement l'entité du magasin sous-jacent ??.

  Même si j'ai un service de domaine ayant une méthode comme void removeEntity(Entity ent), le fait que je dois avoir une méthode publique sur mon interface repo appelé void remove(Entity ent) défaites le but parce que je ne peux pas appliquer cette removeEntity de la couche de service est à être appelé toujours au lieu de remove sur repo et RepoImpl doit avoir une méthode remove pour donner l'implémentation de la suppression d'une entité.

Solution proposée
de ==============
  J'ai cette idée qui semble plutôt artificielle, disons que l'interface de prise en pension a une implémentation abstraite qui a fournit une finale public void remove(Entity ent), l'implémentation abstraite peut faire cette logique pour déterminer si c'est une suppression douce ou dure. Si son une suppression douce est en fait une mise à jour de l'entité avec des drapeaux appropriés fixés, de sorte qu'il appelle this.store(ent) autrement elle enveloppe l'entité dans une DeleteEvent classe

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

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

Notez le constructeur d'accès non publiques, emballage, objets pour cette La classe ne peut être construite qu'à partir de la couche domaine, donc l'autre méthode de suppression sur le RepoImpl est void removeFromStore(DeleteEvent evt) RepoImpl récupère l'entité à partir de ce scellant/support et met en œuvre le processus de suppression.
Bien que cela ressemble à peut travailler est plutôt excentrique/hacky, y at-il un moyen plus propre d'atteindre la même?

Answer 1

Votre principal problème est un manque de langage omniprésent ici. Les suppressions logicielles et les suppressions dures ne sont pas des termes de domaine mais des termes techniques. La première chose que vous devez faire est de reconsidérer votre langage dans les cas d'utilisation autour de l'action de suppression technique. Qu'est-ce que Delete signifie exactement? Je dirais que vous avez besoin plutôt d'annuler, révoquer, expirer, suspendre, interdire, bloquer, terminer, etc. Pensez en termes de état vous mettez votre modèle de domaine à plutôt que des actions CRUD.

Alors la réponse à votre question est: ne jamais effacer.

Plus de lecture: http://www.udidahan.com/2009/09/01/dont-delete-just-dont/