Как репозитории соответствуют CQRS?

Я читал о системах CQRS, которые поддерживают простое хранилище значений ключей на стороне команды для представления состояния приложения, и других, которые просто коррелируют сообщения (используя какую-то сагу) и вместо этого используют хранилище запросов для представления состояния приложения. В любом случае, без сомнения, в этих подходах будет задействована технология персистентности, но шаблон репозитория в этих случаях был бы ненужной абстракцией поверх него.

Однако мой опыт работы с CQRS касался только источников событий, когда мы воспроизводили прошлые события, чтобы перестроить агрегаты, которые инкапсулируют и обеспечивают выполнение бизнес-логики и инвариантов. В этом случае шаблон репозитория представляет собой знакомую абстракцию, которая может предоставить более простой способ получения любого из этих агрегатов.

Что касается стороны запроса, я бы рекомендовал подойти как можно ближе к хранилищу данных, под этим я подразумеваю избегать любых репозиториев, служб, фасадов и т. Д. Между вашим пользовательским интерфейсом (каким бы он ни был) и вашим хранилищем данных.

Возможно, вам будет полезно увидеть пример использования этих подходов. Может быть, взгляните на следующие проекты:

• https://github.com/gregoryyoung/m-r/tree/master/SimpleCQRS
• https://github.com/MarkNijhof/Fohjin
• https://github.com/elliotritchie/NES
• https://github.com/ToJans/Scritchy
• http://ncqrs.org

В случае NES репозиторий просто предоставляет знакомый интерфейс для добавления и чтения агрегатов непосредственно в единицу работы и из нее.

Еще несколько ссылок, которые могут помочь:

• Примеры CQRS и скринкасты
• Ресурсы по источникам событий

Я не уверен, насколько это ортодоксально, но в текущем проекте у меня есть репозиторий для моего совокупного корня сущности. В этом репозитории есть только два метода: Get и ApplyEvents.

Все события реализуют общий интерфейс для своего типа - для заказов есть OrderEvents и т. Д. Я лично поместил бизнес-логику каждого события в полиморфный метод, так что добавление новых типов событий становится очень простым.

Для Get репозиторий переходит в хранилище событий и получает все события в области видимости для данного типа (например, заказы на одно место в магазине). Затем он выполняет воспроизведение событий, чтобы прийти к текущему состоянию объекта для всех заданных событий. Он также может работать с моментальным снимком, поэтому вы не воссоздаете каждое событие при каждой загрузке. У вас также может быть общий репозиторий событий, чтобы даже абстрагироваться от того, как вы храните события, и извлекать их на основе спецификаций.

ApplyEvents принимает список событий, а затем на их основе изменяет состояние объекта и возвращает его. Обратите внимание, что вы даете репозиторию возможность воссоздать объект, а не просто изменить его! Это хорошо работает с функциональным типом программирования, но означает, что лучше избегать равенства объектов (obj1 == obj2) в C # или Java. Я бы сказал, что только ValueObjects, а не Entities, в любом случае должны иметь равенство.

Вот как это работает на практике (C #) - у меня есть заказы, и я хочу добавить элемент. currentOrder.Items возвращает пустой список. Тогда я делаю

Assert.IsFalse(newEvent.Items.Any())
IOrderEvent newEvent = eventFactory.CreateOrderItemEvent(myItemID);
currentOrder = orderRepository.ApplyEvents(currentOrder, newEvent);
Assert.IsTrue(newEvent.Items.Any())

Теперь я должен увидеть currentOrder.Items имеет одну запись.

Недостатком здесь является то, что вся моя обработка выполняется через события, а не моя бизнес-логика в Entity. Однако в моем случае, когда почти все мои объекты должны быть сериализуемыми (в основном POCO) и работать в нескольких системах, это действительно хорошо работает.