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

Question

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

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

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

Я рассмотрел следующие до сих пор:

1. Создание представлений в базе данных для моделей чтения, которые читают все таблицы, наследие и новые
2. Добавить триггеры в существующие таблицы, чтобы обновить новые таблицы модели чтения
3. Добавьте код в базу данных (CLR ХП/и т.д. [SQL Server]), чтобы обновить внешний хранилищу для моделей чтения
4. Оставь надежду

Каково общее мнение о том, как подойти к этому? Неужели глупо думать, что я могу навести порядок в унаследованной системе без полного переписывания всего с нуля?

Answer 1

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

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

Answer 2

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

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

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

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

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

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

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

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