Как проверить поток событий в DDD - Event Sourcing?

Question

Я создаю приложение DDD / CQRS Event Sourcing. (.NET, EventStore)

Я прочитал много статей об этом, особенно известную тему банковского счета.

В качестве напоминания у нас есть следующая последовательность событий:

1. BankAccountCreated
2. Внесено в депозит
3. WithDrawn
4. ChangedOwner
5. Внесено в депозит

Но я так и не нашел сообщение в блогеобъяснить, как проверить последовательность событий? Я имею в виду, что произойдет, если я получу событие Deposited первым, до BankAccountCreated? Другими словами, как я могу проверить, создан ли банковский счет? Как я узнаю, что поток находится в допустимом состоянии?

Нужно ли вызывать модель чтения? каждый раз? в каждом событии? каждый метод совокупности? Что произойдет, если пользователь отправил его дважды, а модель чтения еще не синхронизирована?

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

В моем приложении я не могу применить событие, если «первое» событие (ContactAdded) не существует. Означает ли это, что я должен звонить в EventStore каждый раз, когда мне нужно что-то делать?

Спасибо за вашу помощь.

Answer 1

Там много всего.

Как узнать, что поток находится в действительном состоянии?

Каждый поток должен иметь монотонно увеличивающийся номер версии для каждого события. Событие 1 должно предшествовать событию 2 и т. Д. Для каждого потока (агрегат). EventStore обеспечит этот уровень согласованности, применяя оптимистичный параллелизм. Вы можете предоставить ожидаемую версию потока (например, последнюю написанную версию) при записи событий в хранилище событий. Когда вы читаете свой поток событий, вы берете последний номер версии и передаете его при записи событий в EventStore. Если поток событий увеличился с момента последнего чтения, возникнет ошибка параллелизма.

Должен ли я вызвать модель чтения? каждый раз? в каждом событии? каждый метод совокупности?

Здесь есть некоторая путаница в терминах. Имейте в виду, что модели «События против команд», «Чтение» и «Запись» и какую цель выполняет каждая из них. Вы отображаете данные из вашей модели чтения. Вы проверяете и обрабатываете свою модель записи.

Что произойдет, если пользователь отправил его дважды, а модель чтения еще не синхронизирована?

Учитывая приведенную выше оптимистичную политику параллелизма, вы, по сути, получаете первый ввыигрывает политику. Чтобы обойти проблему, вы можете перехватить ошибки параллелизма и заново обработать вашу команду (получение последнего состояния из EventStore).

Значит ли это, что мне нужно вызывать EventStore каждый раз, когда мне нужно что-то делать?

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

Answer 2

Как проверить поток событий в DDD - Event Sourcing? Как я узнаю, что поток находится в допустимом состоянии?

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

everythingWeKnowNow = domainModel(everythingWeKnewBefore, newInformation)

По мере поступления новой информации, мы интегрируем ее с тем, что произошло раньше, чтобы создать новую версию «истины».

В мире CQRSвсе это происходит в «модели записи» - мы работаем от авторитетного представления «истины», а не устаревшей копии, и мы изменяем ее в соответствии с требованиями домена.

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

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

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

Для частей решения, которые требуют авторитетного упорядочения событий, хитрость заключается в том, что вы извлекаете их из хранилища событий в виде упорядоченной последовательности, не , читая их по одному и пытаясь восстановить последовательность. Другими словами, вы будете использовать модель извлечения, а не модель push для передачи событий из одной системы в другую.

Когда вы работаете в системе, основанной на модели push, и события могутбыть неправильно заказанным, тогда Вы должны встроить это в свой дизайн. Это обычно происходит в форме отслеживания отсутствующей информации и ожидания ее поступления.

(Вы также должны уделять больше внимания time ; время прибытия сообщения - довольно тяжелое времявместо того, чтобы знать, когда что-то произошло).

Распределенные системы сложны , и короткие пути, которые мы узнали, когда все было локально, больше не работают.