A Case Study of the Variability Consequences of the CQRS Pattern in Online Business Software

Оригинал: Kabbedijk, J., Jansen, S. and Brinkkemper S. 2013.A Case Study of the Variability Consequences of the CQRS Pattern in Online Business Software. jn 2, 3, Article 1 (May 2010), 10 pages

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

В таких случаях обычно логика системы разделяется на несколько уровней. Т.к. силу CAP-теоремы невозможно одновременно обеспечить согласованность данных, доступность и устойчивость к разделению, то предлагается сделать акцент на последних двух пунктах и использовать CQRS(command-query responsibility segregation) паттерн. Его главный принцип гласит, что метод должен быть либо командой, выполняющей какое-то действие, либо запросом, возвращающим данные, но не одновременно, т.е. обновление и чтение информации разделено.

Схема, отображающая основной принцип паттерна.

Для данного исследования был произведен опрос в одной компании, разрабатывающей программные системы в Нидерландах. Для архитекторов был проведен опрос, и результаты были обработаны внешними экспертами. Главной целью было выяснить, как использование CQRS паттерна влияет на способность системы адаптироваться под различных пользователей. Для этого были рассмотрены следующие вопросы:

1. Как CQRS паттерн применяется в рамках разработок компании?
2. Какие дополнительные паттерны могут быть использованы вместе с CQRS?
3. Как эти дополнительные паттерны влияют на гибкость системы?

Следующая схема показывает реализацию этого паттерна для разрабатываемой в компании системы.

1. Event Sourcing – подход к работе с данными в виде событий
2. Event Store предполагает хранение последовательной истории событий, все данные могут быть реконструированы в случае отказа системы
3. Agregation root – концепция хранения и обработки свойств, зависящих друг от друга, как агрегации, с выделением главного объекта(root)
4. Command Handler – обработчик команд, интерпретирует одну/несколько команд и передает объекту, способному ее выполнить
5. Query Model Builder первично обрабатывает все события, посылаемые обработчику запросов, создает необходимое представление данных для последнего
6. Query Handler – обработчик запросов, связывает представленные Query Model Builder данные с пользовательским интерфейсом, хранит их и решает, какие должны быть отправлены обратно пользователю после запроса
7. Snapshotting – концепция для систем, хранящих только изменения, а не состояния, т.к. последние можно восстановить зная последовательность изменений, обеспечивает отказоустойчивость как и Event Store.

Данные паттерны не являются обязательными.

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