Следует ли моделировать обратимое удаление на уровне предметной области?

Следует ли моделировать обратимое удаление в объекте DDD или метод удаления репозитория должен делать это сам по себе, не обременяя модель предметной области?

Я не могу сказать, является ли это бизнес-логикой или технической проблемой.

Если это проблема уровня предметной области, где установлен флаг или изменен статус объекта, будет ли это означать, что любой объект, который может быть удален мягко, является объектом, а не объектом значения, поскольку это подразумевает, что объект имеет жизненный цикл?

Объект с обратимым удалением также необходимо отображать в определенных запросах с возможностью восстановления. Означает ли это, что это бизнес-логика и она принадлежит доменному слою?

Вы бы также обработали обратимое удаление и восстановление, изменив флаг объекта и вызвав метод обновления в репозитории? Или есть отдельные методы удаления/восстановления в репозитории?


person peefartpoop    schedule 01.06.2019    source источник


Ответы (1)


Это отличный вопрос,

Он принадлежит репозиторию, технически вашему клиенту все равно, как выполняется удаление. Даже если вы работаете в банке, где ведение документации является требованием, как законным, так и нормативным, это можно рассматривать как техническую проблему.

Тем не менее, это также относится к модели: на стороне домена нет ничего плохого в наличии свойства под названием «заархивировано», «удалено», «удалено» и т.п., которому можно вернуть значение false, если вы хотите отменить Удалить. Такое свойство может быть проверено в качестве предварительного условия для применения команд к вашему объекту, например, для выдачи ошибок при попытке изменить атрибут заархивированного объекта.

Иногда границы размыты, и нет идеального ответа, помните, что нет хороших или плохих моделей, есть только полезные модели.

person Sylvain Lecoy    schedule 03.06.2019