Обложка канала

Архитектура ИС

4563 @it_arch

Разговоры об архитектуре корпоративных информационных систем (архитектура предприятия, архитектура ИТ-решений, микросервисы).

Архитектура ИС

3 года назад
Открыть в
Смотрите какую замечательную вещь предложил Vladimir Khorikov: enterprisecraftsmanship.com/posts/t…-of-cqrs Сделать CQRS "измеряемой" характеристикой: нет CQRS-а, немного CQRS, чуть больше CQRS и т.д. Практически, как REST maturity model от Leonard Richardson. CQRS в нашем решении увеличивается когда: появляются отдельные методы, например для поиска; разделяются классы для работы с данными и их сохранения, выделяются разные модели для чтения и записи, чтение выделяется в отдельный(ые) сервисы, разделяются системы хранения данных для чтения и записи. Каждый следующий шаг - это не бесплатно. Зато по мере увеличения CQRS-ности решения улучшаются его характеристики (возможность независимого масштабирования команд и запросов, локализация изменений и т.п.). Ну, т.е. не надо спорить нужен CQRS или нет. Надо обосновывать сколько его нужно в данном конкретном случае и зачем
Types of CQRS

CQRS is a pretty defined concept. Often, people say that you either follow CQRS or not, meaning that it is some kind of a binary choice. In this article, I’d like to show that there is some wriggle room in this notion and how different types of CQRS can look like. Type 0: no CQRS With this type, you don’t have any CQRS whatsoever. That means you have a domain model and you use your domain classes for both serving commands and executing queries.

Enterprise Craftsmanship