Comments 2
Вводя понятие основной проекции переизобретается велосипед снапшот - это построенный по первым N ивентам слепок агрегата. Тогда если в команде нужен агрегат, он строится не по всем ивентам, а начиная с N+1. Если снапшот обновлять после каждого нового ивента, то получится ровно то, что в статье называется основной проекцией.
Кстати снапшот никак не влияет на eventual consistency. Не важно, строится в команде агрегат по всём ивентам с первого или с N+1, всё равно между добавлением ивентов в ивент стор и обновлением проекций для чтения будет лаг.
Спасибо за комментарий)
Вводя понятие основной проекции переизобретается
велосипедснапшот - это построенный по первым N ивентам слепок агрегата. Тогда если в команде нужен агрегат, он строится не по всем ивентам, а начиная с N+1. Если снапшот обновлять после каждого нового ивента, то получится ровно то, что в статье называется основной проекцией.
Все-таки снапшот -- это обычно тоже событие. Соответственно, он сокращает количество проигрываемых событий при построении агрегата. Это же проекция, но с необходимой полнотой данных, чтобы не нужно было отдельно строить агрегат, и с единой транзакцией с событием, которая исключает eventual consistency.
Кстати снапшот никак не влияет на eventual consistency. Не важно, строится в команде агрегат по всём ивентам с первого или с N+1, всё равно между добавлением ивентов в ивент стор и обновлением проекций для чтения будет лаг.
Да, классический снапшот никак не влияет, но основная проекция -- не снапшот (в классическом смысле). Идет 1 транзакция на БД с созданием события и обновлением основной ("встроенная" даже более точное определение) проекции, так что это уже никак не отличается по консистентности от обычных (не event sourcing) систем.
Опять же, я не считаю это каким-то своим изобретением -- нечто подобное наверняка есть и у других. Моя роль скорее подсветить этот вариант и показать пример реализации.
Inline Event Sourcing