Обработка обновлений пассивного удаления (т.е. архивирование вместо удаления)

Question

Мы разрабатываем приложение, основанное на принципах DDD. До сих пор мы столкнулись с несколькими проблемами, поэтому не можем ответить и не можем найти ответы в Интернете.

Наше приложение предназначено для использования в облаке для нескольких компаний.

Одним из требований является отсутствие физических удалений из базы данных. Мы делаем только пассивное удаление, устанавливая свойство Active для сущностей в false. Это касается операций выбора, вставки и удаления, но мы не знаем, как обрабатывать операции обновления.

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

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

В настоящее время мы используем ASP.NET MVC с EF CF для хранилища, но одно из требований заключается в том, что мы можем легко переключать или добавлять другие технологии, такие как WPF или WCF. В настоящее время мы используем Automapper для сопоставления DTO с объектами Domain, и наоборот, и DTO являются основным источником для представлений, т.е. у нас нет моделей просмотра. Приложение разбито на слои по принципу DDD, а сопоставление происходит на уровне сервиса.

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

Любые комментарии или предложения приветствуются. Мы также приветствуем любые изменения в требованиях (поскольку это внутренний проект, а не для клиента) и архитектуры, но только в том случае, если это абсолютно необходимо.

Спасибо.

Answer 1

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

Answer 2

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

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

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