CQRS (Command and Query Responsibility Segregation) pattern
Сегодня про архитектурный паттерн CQRS, суть которого состоит в том, чтобы отделить операции изменения от операций чтения.
Плюсы:
— Независимое масштабирование читающей и пишущей моделей
— Оптимальные методы и схемы данных для записи и для чтения
— Безопасность (легко обеспечить, чтобы только разрешенные поставщики меняли данные).
— Разделение проблем читателей и писателей (бизнес-логика может остаться в модели изменения данных, при этом модель чтения окажется очень простой)
— Простые запросы.
Пример.
Функциональность "пользователь логинится в приложение, нужно отображать список активных пользователей" требует разные модели изменения состояния и чтения данных.
Следуя паттерну, такую функциональность легко разделить на команды (command): "пользователь активен" и запросы (query): "выбрать список активных пользователей".
Можно использовать event-log для хранения информации о времени активности пользователя и использовать ее как "источник правды".
В то же время, для запросов можно использовать более оптимизированное для чтение хранилище.
Таким образом, сохраняя команду "пользователь активен", мы синхронизируем ее с in-memory хранилищем активных пользователей c TTL, на который мы считаем пользователя активным. Читающие клиенты будут использовать ее для чтения.
По ссылке подробно про то, какие есть плюсы и минусы такого подхода, когда нужно и когда не нужно использовать этот паттерн, а также пример синхронизации моделей записи и чтения.
https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs
#pattern #microservices #practices #doc #en
Сегодня про архитектурный паттерн CQRS, суть которого состоит в том, чтобы отделить операции изменения от операций чтения.
Плюсы:
— Независимое масштабирование читающей и пишущей моделей
— Оптимальные методы и схемы данных для записи и для чтения
— Безопасность (легко обеспечить, чтобы только разрешенные поставщики меняли данные).
— Разделение проблем читателей и писателей (бизнес-логика может остаться в модели изменения данных, при этом модель чтения окажется очень простой)
— Простые запросы.
Пример.
Функциональность "пользователь логинится в приложение, нужно отображать список активных пользователей" требует разные модели изменения состояния и чтения данных.
Следуя паттерну, такую функциональность легко разделить на команды (command): "пользователь активен" и запросы (query): "выбрать список активных пользователей".
Можно использовать event-log для хранения информации о времени активности пользователя и использовать ее как "источник правды".
В то же время, для запросов можно использовать более оптимизированное для чтение хранилище.
Таким образом, сохраняя команду "пользователь активен", мы синхронизируем ее с in-memory хранилищем активных пользователей c TTL, на который мы считаем пользователя активным. Читающие клиенты будут использовать ее для чтения.
По ссылке подробно про то, какие есть плюсы и минусы такого подхода, когда нужно и когда не нужно использовать этот паттерн, а также пример синхронизации моделей записи и чтения.
https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs
#pattern #microservices #practices #doc #en