Использование CQRS для улучшения устаревшей монолитной системы

Question

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

Теперь мне нужно предоставить несколько новых API-интерфейсов нескольким клиентам. Чтобы реализовать эти API, мне нужно создать новые записи или объединить несколько записей из прежней системы.

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

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

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

Любое предложение будет высоко оценено.

Answer 1

CQRS определенно не только для гринфилда. Преобразование больших унаследованных систем в CQRS может быть успешно выполнено, просто требуется немного изящества и времени.

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

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

После того, как события на месте, нужно просто набросать код для поддержки стороны чтения, что является трудоемким, но тривиальным.

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

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