CQRS с устаревшими системами

Я использовал вариант № 1 с успехом. Создание представлений для деморализации данных для создания модели чтения является жизнеспособным вариантом в зависимости от сложности базы данных для записи. Это означает, что если это относительно прямое соединение, понятное большинству разработчиков, я бы внимательно посмотрел, подходит ли оно для вас. Я был бы осторожен со слишком большой сложностью в этих представлениях.

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

Я когда-то был в похожей ситуации, следующие шаги были такими, как я это сделал:

Чтобы улучшить унаследованную систему и добиться более чистой кодовой базы, важно взять на себя ответственность за написание. Но не будьте слишком амбициозны, так как это может привести к изменению интерфейса/контракта, что сделает окончательное развертывание рискованным.

1. Если все записи запускаются через что-либо, кроме прямых обновлений sql, сохраняйте их обратную совместимость, насколько это возможно. Возьмите их в качестве адаптеров/клиентов ваших недавно разработанных обработчиков команд.

2. Некоторые записи являются прямыми обновлениями SQL, но не под вашим контролем.
   Спросите ответственную группу, могут ли они перейти на ваш новый интерфейс/контракт?
   Если нет, см. шаг 3.

3. Спросите, могут ли они допустить возможную согласованность и готовы ли заменить обновления sql процедурами базы данных?
   Если да, поместите все обновления sql в процедуры и запланируйте развертывание и см. шаг 4.
   Если нет, возможно, вы следует включить их в ваш рефакторинг.

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

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

6. Перейдите к следующей части устаревшей системы.

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

Я добился успеха с решением, которое менее навязчиво, чем решение @Hippoom, но более отзывчиво, чем решение @Derek. Если у вас есть доступ к устаревшей системе и вы можете вносить незначительные изменения в код, вы можете добавить асинхронную запись в очередь для генерации события в системе очередей (RabbitMQ, Kafka или любой другой) в репозиториях устаревшей системы или везде, где данные сохраняются. Выполнение этих асинхронных операций записи не должно приводить к значительным потерям производительности, и в случае сбоя записи очереди это не повлияет на устаревшую систему. Это изменение также довольно легко получить через QA.

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