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

Откуда берётся этот общий поток?
Давайте конкретный простенький пример. Есть скажем агрегат User (пользователь). У него например есть команды Создать (Create) и Добавить паспортные данные (AddPassport)
Его состояние хранится не в виде записи в РСУБД. А в виде двух событий UserCreated и PassportAdded связанных с идентификатором.
При чем здесь поток событий?

А откуда появится AddPassport?
Есть контекст "Управление пользователями", в котором куча агрегатов - профили, KYC, аккаунты и что там еще появяется.
И есть поток событий от конечных систем на "Создать новый профиль", "Изменить тариф", которые превращаются уже в "AddPassport, "CreateUser", "SetUserKYCLevel" ....
И повторять имеет смысл (при ошибках) именно весь поток на контекст (возможно как-то фильтруя по тому, к кому событие относится).

Вообще не важно как приходят команды. Это другой архитектурный слой (DomainLayer)
Исходные сигналы рождаются в слое внешних адаптеров (Adapters Layer). В качестве адаптеров может быть REST API, очередь и т. д. То есть вид и количество адаптеров не имеет значения.

Ну вот между адаптерами и контекстом и интересна очередь. Собственно, очередь сигналов на контекст.

Смысл мне хранить историю изменения отдельного агрегата, если ее все равно нет смысла применять без изменения других?

Нет никаких очередей между уровнями. Все виды очередей это всегда адаптеры. Здесь почитайте. https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexagonal-onion-clean-cqrs-how-i-put-it-all-together/#application-layer

Такое ощущение что речь вы об одном ведете, только словарь разный

Это один из вариантов архитектуры, не единственный же...

Я говорил про свой простой пример. В вашем случае сначала нужно провести доменное моделирование.
Скорее всего будет несколько агрегатов. Например UserRegistrationProcess - оркестратор и User

Ну, там же в рамках этот оркестратора же много агрегатов будет затронуто?

Я рассказал что есть ES и  в чем разница например с Event Bus

UserRegistrationProcess - это куча изменений даже в разных контекстах может быть. И если повторять их - то нужно все.

Я не знаю. Нужно доменное моделирование.

Т.е. source-of-truth - это запрос на регистрацию пользователя. Целиком, как есть.

У каждого агрегата свой набор команд и событий. Каждый агрегат логически автономен

Пользовательская команда может менять несколько агрегатов?

Это вопрос к чему?

Я уже перестал понимать о чем мы спорим.

Ладно спать пора