У меня есть сценарий, в котором данный объект может быть помечен для мягкого удаления или жесткого удаления на основе некоторой логики, когда пользователь запрашивает удаление.
Приближая эту проблему из парадигмы 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 получает сущность от этого герметика/держателя и реализует процесс удаления.
Это, хотя похоже, может работать довольно изворотливым/взломанным, есть ли более чистый способ добиться того же?
DDD признает понятие удаления не так ли ?? поэтому, когда интерфейс репозитория имеет метод, называемый «void remove (Entity ent)», что должен реализовать implemntor? И так как вы упомянули об этом, как отображать действия пользователя CRUD на действия домена? так что, очевидно, что пользователь знает как delete, здесь не удаляется (в некоторых ситуациях). В этом контексте вездесущий язык не распространяется на пользователя, не так ли? – redzedi
Я бы сказал, что метод удаления должен установить Deleted = true или что-то simmilar. – Pein
Если ваш пользователь выполняет только действия CRUD, вам действительно нужен DDD или просто пересмотр вашего проекта? – Pein