Сегодня была интересная дискуссия про soft delete (ака мягкое удаление, но мне не нравится как это звучит на русском). Что такое soft delete и как обычно его реализуют? Если мы говорим про sql базы данных, то обычно добавляют колонку is_deleted (и в довесок всякие deleted_at, deleted_by) и вместо DELETE FROM table_name where id =@id используют UPDATE table_name SET is_deleted=true where id = @id. Кроме этого во всех запросах (как минимум на чтение) добавляют предикат is_deleted=false. Какая польза? 1. Мы не теряем данные и можем получать более полную картинку для аудита, аналитики и прочего. 2. Если кто-то (пользователь, крон) некоректно удалил что-либо, то мы можем восстановить данные без сложных манипуляций с бекапом (которого еще может и не оказаться). 3. Есть выигрыш по перфомансу на массовых операциях удалени. Минусы тоже есть: 1. Код сложнее, надо не забывать везде отфильтровывать. 2. Перфоманс может страдать, если записей в таблице много и процент is_deleted достаточно большой, то надо будет что-то придумывать дополнительное (самое простое индекс по полю is_deleted). 3. Может пострадать доверие пользователя -- я не рекомендую (в общем случае) использовать soft delete на реально чувствительных для пользователя данных без дополнительных механизмов гарантии невосстановления. Иногда приходит требование реализовать пользовательскую логику удаления/восстановления в корзину. И часто есть соблазн переиспользовать механизм soft delete для этих целей: 1. Удаление в корзину через set is_deleted=true 2. Восстановление через set is_deleted=false 3. Получение списка сущностей в корзине -- выборка с предикатом is_deleted=true 4. Удаление из корзины через hard delete. Вроде все норм, разработчик ушел делать. Но если посмотреть на это через призму DDD? Если обобщать, то у нас есть технические (инфраструктурные) решения и решения продиктованные бизнес-логикой. 1. Технические решения должны быть простыми (насколько это возможно), ничего не знать про бизнес-логику, не подвергаться регулярным изменениям, быть общими для всех сущностей. 2. Имплементация бизнес-логики наоборот должна максимально много знать про то что происходит и следовать этому знанию в том числе в нейминге: удалено, в корзине, скрыто, дезактивировано -- все это выглядит похоже, но несет различную смысловую нагрузку. 3. Бизнес-логика обычно чаще меняется и имеет тенденцию к усложнению: со временем нужно будет дать права на просмотр корзины и восстановление, необходимо будет учесть время или еще какие-то признаки. 4. Многие сущности будут требовать и технического решения и бизнесового: например даже после удаления из корзины, мы хотим иметь доступ к сущности для аудита. Soft delete это техническое, в первую очередь, решение. Удаление в корзину, это решение которое продиктовано бизнес-логикой. Я категорически не рекомендую смешивать такого радо механизмы, как бы они не выглядели похожими.