2012-07-25 5 views
0

У меня есть сценарий, в котором данный объект может быть помечен для мягкого удаления или жесткого удаления на основе некоторой логики, когда пользователь запрашивает удаление.

Приближая эту проблему из парадигмы DDD, я вижу некоторые проблемы: - DDD предлагает использовать объект репозитория для всех связанных с сохранением свойств, где слой домена просто определяет такой интерфейс репо (содержащий типичные методы, такие как сохранение, удаление, поиск) и уровень инфраструктуры, содержащий фактическую реализацию. Учитывая, что для моей проблемы здесь, тогда логика, которая решает, следует ли выполнять мягкое удаление или нет, принадлежит доменному слою, как можно содержать логику в доменном слое таким образом, чтобы безопасность, которую любой запрос на удаление любым другим слой направляется через эту логику, прежде чем перейти к точке фактического вызова delete на RepoImpl, который фактически удаляет объект из основного хранилища.

  Даже если у меня есть обслуживание домена, имеющее метод, как void removeEntity(Entity ent), тот факт, что я должен иметь открытый метод на моем интерфейсе репо под названием void remove(Entity ent) поражений цели, потому что не могу обеспечить, что removeEntity сервисный слой является всегда вызываться вместо remove на repo, и RepoImpl должен иметь метод удаления, чтобы обеспечить реализацию удаления объекта.

Предлагаемое решение
==============
  у меня есть идея, которая выглядит довольно надуманный, скажем, интерфейс Repo имеет абстрактную реализацию, которая имеет обеспечивает окончательное public void remove(Entity ent), абстрактная реализация может сделать эту логику, чтобы определить, является ли ее мягким или жестким удалением. Если его мягкое удаление ее на самом деле обновление объекта с надлежащими флагами, поэтому он называет this.store(ent) иначе она оборачивает объект в DeleteEvent классаsoft delete in DDD

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 получает сущность от этого герметика/держателя и реализует процесс удаления.
Это, хотя похоже, может работать довольно изворотливым/взломанным, есть ли более чистый способ добиться того же?

ответ

2

Ваша основная проблема - отсутствие вездесущего языка здесь. Мягкое удаление и жесткое удаление - это не термины домена, а технические. Первое, что вам нужно сделать, это пересмотреть свой язык в случаях использования вокруг действия «Удалить». Что означает «Удалить»? Я бы сказал, что вам нужно скорее «Отменить», «Отменить», «Истекать», «Приостановить», «Запретить», «Блокировать», «Готово» и т. Д. Подумайте с точки зрения , состояние вы помещаете свою модель домена, а не CRUD-действия.

Тогда ответ на ваш вопрос: никогда не делайте жесткого удаления.

Больше чтение: http://www.udidahan.com/2009/09/01/dont-delete-just-dont/

+0

DDD признает понятие удаления не так ли ?? поэтому, когда интерфейс репозитория имеет метод, называемый «void remove (Entity ent)», что должен реализовать implemntor? И так как вы упомянули об этом, как отображать действия пользователя CRUD на действия домена? так что, очевидно, что пользователь знает как delete, здесь не удаляется (в некоторых ситуациях). В этом контексте вездесущий язык не распространяется на пользователя, не так ли? – redzedi

+0

Я бы сказал, что метод удаления должен установить Deleted = true или что-то simmilar. – Pein

+1

Если ваш пользователь выполняет только действия CRUD, вам действительно нужен DDD или просто пересмотр вашего проекта? – Pein