Агрегат магазина событий CQRS против проекции

в хранилище событий CQRS содержит ли "агрегат" обобщенное представление событий или просто ссылку на границу этих событий? (идентификатор группы)

агрегаты не существуют в хранилище событий

• события живут в магазине событий
• агрегаты живут в модели записи (C из CQRS)

Aggregate, в этом случае, все еще имеет то же основное значение, что и в "Голубая Книга"; это термин для границы вокруг одного или нескольких объектов, которые непосредственно согласуются друг с другом. Ответственность агрегата заключается в обеспечении того, чтобы записи (команды) в книгу записей уважали бизнес-инвариант.

обычно в магазине событий удобно организовывать события в "потоки"; если вы представляете РСУБД-схемы, идентификатор потока будет просто некоторым идентификатором, который говорит: "эти события являются частью одного и того же история."

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

таким образом, возможно, что одна и та же структура данных может существовать в хранилище aggregate и query (Дублированное представление, используемое для разных целей).

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

есть ли шанс, что у вас есть пример структуры данных агрегированного состояния (СУБД)? Каждый пример, который я нашел, обрезается до нескольких столбцов с чем-то вроде include id, source_id, version, что затрудняет визуализацию области агрегата

распространенным примером может быть торговая книга (совокупность, ответственная за сопоставление ордеров "купить" и "продать").

в традиционном магазине СУБД, который, вероятно, будет выглядеть как строка в таблице книг, с уникальным идентификатором книги, информацией о том, какой элемент отслеживает книга, информацией о дате, когда эта книга активна, и так далее. Кроме того, вероятно, будет какая-то таблица ордеров с идентификаторами uniq, идентификатором торговой книги, типом ордера, номерами транзакций, ценами и объемами (другими словами, вся информация, которую агрегат должен знать, чтобы удовлетворить свой инвариант).

в хранилище документов вы увидите всю эту информацию в одном документ-возможно, документ json с информацией о корневом объекте и два списка объектов заказа (один для покупки, один для продажи).

в магазине событий вы увидите человека OrderPlaced, TradeOccurred, OrderCancelled.

кажется, что агрегат вычисляется с использованием всего набора событий, если он не становится достаточно большим, чтобы гарантировать снимок.

да, именно так. Если вы знакомы с "функцией сгиба", то событие sourcing - это просто складка из некоторого общего начального состояния. Когда снимок будет доступен, мы сложим из этого состояния (с соответствующим уменьшением количества событий, которые складываются)

в среде источника событий с "моментальными снимками" вы можете увидеть комбинацию хранилища событий и хранилища документов (где документ будет включать дополнительную метаинформацию, указывающую, где в потоке событий он был собран).