Каждое приложение — уникально и заслуживает особого подхода.
К счастью, у разработчиков приложений есть замечательный выбор архитектурных стилей и принципов, которые можно применить и даже идеально сочетать между собой.
Рассмотрим принцип разделения команд и запросов (CQRS) в разработке приложений.
CQRS (Command Query Responsibility Segregation): в чем заключается принцип
Именно разделение ответственности лежит в основе CQRS — принципа, который был предложен Грегом Яном и Уди Дахан. CQRS черпает свою суть из другого принципа — CQS (Command Query Separation), автором которого является Бертран Мейер. Любой метод должен или изменять состояние объекта, или возвращать результат — но не то и другое одновременно. Так Бертран Мейер описал основную идею CQS.
Принцип разделения ответственности между командами и запросами (CQRS) также базируется на этой философии. CQRS — архитектурный шаблон, который предусматривает разделение приложения на две отдельные модели данных. Одна из них отвечает за обновление данных (операции по написанию), другая — за отображение данных (операции по считыванию). Согласно терминологии вышеупомянутого CQS, эти операции известны как команды и запросы.
Команды VS запросы: строгое распределение ролей
Каждая операция — это либо команда или запрос, и не может быть сочетанием обоих.
Команда (также известная как модификатор) вносит изменения в систему, но не возвращает данные. Запрос, наоборот, получает и отображает данные из системы, но не может их менять.
Запросы имеют тип «return», а команды не возвращают значение, то есть «void». Команды и запросы не могут обмениваться ролями. Таким образом, одна часть вашего приложения сконцентрирована исключительно на обработке команд, а другая — исключительно на отражении данных.
При выполнении различных баз данных
Работая по принципу CQRS, вы можете использовать одну базу данных для обеих моделей своего приложения. Пользователь дает команду, согласно которой модель, отвечающая за обновление информации, вносит изменения в базу данных, а модель, работающая со считыванием информации, делает запрос к базе данных и выводит результат.
Однако, популярным решением, которое полностью отражает философию CQRS, является работа с отдельными базами данных. Команды отправляются в одной базе, данные там обрабатываются и передаются в другую базу, соответственно обновляется. Этот подход позволяет повысить производительность, масштабируемость и безопасность.
Преимущества CQRS
Одна из самых больших преимуществ CQRS — возможность расширять и оптимизировать каждую из сторон приложении независимо друг от друга. Вы можете создать лучшие условия для каждой из них, никак не задев «интересов» другой. Это повышает производительность и дает вам больший простор для внесения изменений в будущем.
Разделение ответственности возможно не только для программного обеспечения, но и для людей, которые работают над его созданием. Очень эффективным решением может быть распределение работы между отдельными командами разработчиков. Например, более опытная команда могла бы отвечать за «командную» часть, содержащую сложные алгоритмы обработки информации, а менее опытная — работать с частью вывода данных без необходимости углубляться во все процессы первой.
CQRS также даст вам возможность создать интерактивный, задача-ориентированный интерфейс, в котором основное внимание уделяется намерениям пользователя.
Command Query Responsibility Segregation прекрасно сочетается с другим подходом, называется Event Sourcing. Его суть — в хранении всех данных системы в виде событий.
Хотя принцип разделения команд и запросов может творить чудеса, его нужно использовать осторожно и только когда это использование оправдано. Ведь он должен лишать приложение чрезмерной сложности, а не добавлять ее.
CQRS — это отход от традиционного принципа CRUD, который предусматривает единую модель для создания, чтения, обновления и удаления (creating, reading, updating and deleting) информации. Для многих систем CRUD является абсолютно достаточным, поэтому в CQRS нет необходимости.
Некоторые случаи, в которых прекрасно подойдет CQRS
приложения с неровным нагрузкой, например, с большим количеством запросов и малым количеством обновлений; другие случаи, когда каждая из сторон приложении требует отдельного настройки; сложные домены; системы со сложной бизнес-логикой; сложная обработка данных; меняющиеся бизнес-условия, ожидаемые изменения в приложения.
Всегда существует идеальное решение для каждого приложения — Command Query Responsibility Segregation (CQRS) или другое!