Я дам вам некоторые основные термины, которые я использовал / видел-использовал.Кроме того, я буду использовать источник событий в контексте CQRS, хотя его можно использовать отдельно (я этого не делал до сих пор).
Хранилище событий - это постоянство (база данных) событий.Стороны записи / команды и чтения / запроса приложения имеют различные требования к хранилищу событий.
Сторона записи требует, чтобы события, генерируемые Агрегатом, были в порядке и были защищеныиз одновременных вставок .Люди называют это Поток событий = все события, генерируемые экземпляром Aggregate (т. Е. Product # 1234).Поток событий также должен быть быстрым при чтении, то есть чтение всех событий из потока событий в том порядке, в котором они были отправлены, самый старый из первых, должен быть очень быстрым;это необходимо для повторной гидратации агрегата перед выполнением каждой команды.
Сторона чтения хотела бы, чтобы все события были в порядке total во всех агрегатах.Если вы позволите себе это требование, тогда Readmodels проще построить.Однако при более значительных усилиях по разработке и проектированию можно создавать модели чтения, которые не требуют полного порядка.
Проблема с большими системами заключается в том, что в целом модели чтения требуют событий из нескольких хранилищ событий * 1017.*
Является ли источник события коллекцией потоков событий?
Если под "источником события" подразумевается "Хранилище событий", то ДА.
Будет ли у вас источник события в ограниченном контексте?Или, может быть, для DDD Aggregate (например, для автомобиля и его изменений)?
Самая простая система - это система с одним экземпляром хранилища событий.Это связано с тем, что тогда Readmodels нужно подключиться только к одному экземпляру, и вы можете иметь общий порядок событий.
Если система слишком большая, наличие одного хранилища событий невозможно.Это означает, что вы не можете иметь полный порядок событий, а это означает, что Readmodels сложнее построить (не невозможно), и эксплуатационные расходы возрастают.
Итак, вы должны сделать компромисс.Один хороший компромисс - наличие хранилища событий для ограниченного контекста.
Будет ли у каждого источника событий свое хранилище данных?
Этот вопрос не имеет смысла в контекстеэтого ответа.Одно хранилище событий = одно хранилище данных.
Будет ли в качестве примера источник события автомобиля, где каждый поток событий основан на уникальном идентификаторе carId?
Да,каждый экземпляр автомобиля (имеющий уникальный идентификатор) имеет поток событий.
client -> API EventStore -> сохранить событие -> возможно опубликовать сообщение в очередь -> Ack toклиент дает большие пальцы -> иди строить свои прочитанные модели / индексы?-> клиент публикует событие публично -> другие потребители этого же события теперь могут предпринимать действия, основанные на этом событии.
Это зависит от вашей архитектуры / стиля / того, как считывающие модули получают события.
У вас может быть простая синхронная система, когда в одном и том же процессе / потоке обрабатывается команда, события отправляются, они немедленно сохраняются в хранилище событий, затем все Readmodels и Sagas снабжаютсявсе эти новые события выполняются синхронно, одно за другим.
Более сложная система выполняет команду, сохраняет события в хранилище событий, а затем возвращает ответ клиенту.В отдельном процессе Readmodels и Sagas опрашивают новые события из хранилища событий (которое предоставляет такой API) и обрабатывают их в фоновом режиме.
Другие решения используют очереди сообщений;это несколько трудно сделать, потому что невозможно безопасно и в масштабируемом способе сохранить события в хранилище событий и опубликовать их в очереди сообщений атомарным способом (оба успешно или нет)).