Comments 11
Интересно, не думал, что CQRS подразумевает отказ от ORM. Думал, что на инфраструктурном уровне вполне в write модель использовать ее допустимо, так как пишется данных меньше, чем читается. А на read уровне, да, можно просто доставать данные запросом.
В CQRS отказываются от ORM (Object-Relational Mapping) в пользу использования агрегатов (Aggregates), которые представляют связанные сущности в приложении и содержат логику их изменения состояния
Непонятно, как ORM можно заменить агрегатом. Более того, агрегаты - это из DDD, что то не припомню ничего такого в CQRS.
не думал, что CQRS подразумевает отказ от ORM.
Выглядит как фантазия автора статьи
У автора смешалось в кучу CQRS, DDD, и ES (Event Sourcing). Оно часто идет бок о бок, но всё же это отдельные вещи.
Кроме того:
Команды обычно обрабатываются с помощью синхронных запросов, ... Запросы, с другой стороны, могут обрабатываться с помощью асинхронных запросов
всё ровно наоборот. Команда, поскольку не возвращает никаких данных, просто отправляется в очередь на выполнение обработчиком, клиент, если надо, при этом подписывается на события, которые выполнение этой команды может вызывать. Запрос же, наоборот, возвращает данные, поэтому клиенту так или иначе надо дожидаться его выполнения.
В реляционной бд агрегаты как раз таки удобнее собирать с помощью орм.
А вообще CQRS как архитектурный принцип отлично существует и без ddd с его агрегатами и без event sourcing’a. Да, CQRS может быть хорошим помощником при построении event source приложения, но это не одно и то же. Тут статья вводит в заблуждение.
Расскажите пожалуйста как в вашем примере не продать дважды один товар?
Если вы считаете остатки по таблице Events, то у вас не будет преимущества в скорости работы. Если вы остатки пересчитываете асинхронно, то вы сможете продать то, чего нет. Если вы остатки пересчитываете синхронно, то смысл в отдельной write-модели пропадает.
Например, можно разруливать чем-то похожим на оптимистичную блокировку. При чтении агрегата считывается "timestamp" его последнего события, если мы хотим записать для него новое событие (например "продажа"), то проверяем снова этот "timestamp", и если он увеличился, то перезапускаем нашу транзакцию (например повторно кладем в очередь команду которая её инициировала).
Идея CQRS возникла в 2010 году, когда Грег Янг
Этой идее десятки лет и Янг к ней никакого отношения не имеет.
Люди читают курс Enterprise Architect - то есть являются гуру в этой сфере и в тоже время дают такую информацию - "В CQRS отказываются от ORM (Object-Relational Mapping) в пользу использования агрегатов (Aggregates)". Это выглядит странно.
Архитектура CQRS