Является ли целостность базы данных из-за concurrency проблем ответственностью бизнес логики?
===============================================================================================

 Есть дерево объектов. В бизнес логике удаление происходит так:   

1) Найти дочерние элементы объекта  

2) Удалить каждый дочерний объект  

3) Удалить сам объект  

  

Проблема в том, что во время удаления дочерних объектов может появиться новый дочерний объект, который не включен в массив, полученный на первом шаге. Вопрос - кто эту проблему должен разрулировать? Размазываем ли мы бизнес логику в базе данных или наоборот логику базы данных в бизнес логике? Есть два варианта:  

  

1) Бизнес логика после всех шагов проходит по таблице и ищет листья без родителей  

2) База данных сама разруливает всё с помощью foreign key, delete cascade, блокировок таблиц  

  

Является ли это проблемой concurrency бизнес-логики или проблемой целостности базы данных? На каком уровне это должно разруливаться? 

 Бизнес-логика вообще ничего не должна знать ни про базу данных, ни про механизмы целостности, ни про конкурентность. С базой должен работать инфраструктурный код, который должен эксплуатировать её механизмы наиболее полно и эффективно. То есть в случае удаления дерева, как в вашем примере, однозначно второй вариант. 

 Конкретно описанная проблема решается не бизнеслогикой, никто этим уже давно не занимается, так как сами базы данных умеют это контролировать (транзакции и блокировки на уровне таблиц или даже объектов, если поддерживается). Само собой код нужно делать с оглядкой на подобные конфликты (например не считать количество до блокировки редактирования, если это количество требуется тут же).  

  

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

  

Еще существуют ситуации, где бизнеслогика определяет сложное правило слежения за целостностью базы, например смена статусов не может проходить вне оговоренного порядка, например не перескакивать статусы, которые должны идти в определенном бизнеслогикой порядке, или, к примеру, количество связей 1-м может быть определено сложным правилом (на интервале с константными значениями к примеру от 2 до 7, когда как реляционная база данных в лучшем случае оперирует значениями 0,1 или много, или даже когда эти количества зависят от значений и статусов), т.е. все то чем не пока не умеют автоматически заниматься традиционные реляционные базы данных, должен делать кто то другой, т.е. код на бакэенде (ни дай бог только на фронтэнде, ибо тогда это дыра).  

  

Красиво и правильно это реализуется соответствующей прослойкой, **например функциями в базе данных на встроенном языке программирования** или же на бакэнде, когда программисты договариваются не работать с базой напрямую, а только через эту логическую прослойку. Т.е. обслуживающий персонал уже не должны подключаться к базе напрямую и править таблички, а только через вызовы методов этой прослойки.  

  

Иначе за этим придется ответственно следить, контролируя корректность данных на уровне реализации интерфейса и валидации введенных данных, и главное корректно это документировать, для будущих страдальцев такой бардак поддерживать.