Идея, лежащая в основе Источника событий для вашего агрегата, заключается в том, что эти события являются источником для любой модели в вашей системе.
Таким образом, если вы создаете специальную командную модель для обработки описанных вами команд, то эта модель (которая с точки зрения Axon является классом аннотации @Aggregate(Root)) будет получена из событий, которые она опубликовала.
Кроме того, вы можете ввести любой тип модели запроса, какой захотите; представление RDBMS, решение для текстового поиска (например, Elastic), база данных временных рядов, вы называете это. Однако любая из этих моделей запросов по-прежнему является частью того же корневого приложения, в котором находится ваш агрегат. Поскольку у вас есть события в качестве средства уведомления других о принимаемых решениях, естественно (повторно) использовать их для обновления всех ваших моделей запросов. также.
Совершенно верно, что вы не склонны использовать Event Sourcing для своих агрегатов в Axon, который с его точки зрения называется State-Stored Aggregate. Однако, если вы сделаете это, вы вернетесь к отдельным моделям в отдельном механизме хранения без единого источника истины.
Итак, чтобы вернуться к вашему вопросу с этими дополнительными знаниями, я бы сказал следующее:
Например, когда мне следует вручную воссоздать агрегат?
Вы никогда не будете склонны воссоздавать агрегат как командную модель, поскольку фреймворк делает это за вас. Если у вас есть зеркальный агрегат модели запроса, вы должны воссоздавать его всякий раз, когда вы добавляете / удаляете / изменяете поля в модели. Или, если вы представили совершенно новые модели.
Какая польза от воссоздания агрегата каждый раз, когда я вызываю команду?
Преимущество его воссоздания каждый раз - гарантия того, что вы всегда будете использовать последнее состояние. Даже если между выпуском вашего приложения вы добавили / изменили / удалили новые поля. @EventSourcingHandler аннотированные методы просто заполнят их, и вам не нужно будет, например, писать сценарий базы данных, чтобы настроить его напрямую на уровне базы данных.
В заключение следует отметить, что причина такого подхода полностью лежит в архитектурных концепциях, поддерживаемых Axon. Вы можете прочитать о них на странице AxonIQ Архитектурные концепции, если хотите; Я уверен, что это еще больше прояснит ситуацию.
Надеюсь, это поможет вам @ Gisrou8! Если нет, ответьте, пожалуйста, на другие вопросы, я бы с радостью объяснил кое-что еще.
Обновление: дополнительное объяснение модели команд
Из комментария Gisrou8, помещенного под моим ответом, становится очевидным, что «беспокойство» с этим подходом в основном связано с состоянием Агрегата.
Как уже упоминалось в моем предыдущем ответе, Агрегат, который можно смоделировать с помощью Axon Framework, должен рассматриваться в настройке Event Sourced как командная модель в системе CQRS.
Один из основных столпов Командной модели заключается в том, что единственное состояние, которое она содержит, является состоянием, необходимым для логики принятия решений. Чтобы быть более конкретным в отношении последнего, единственное состояние, хранящееся в вашем агрегате, - это состояние, используемое для определения того, должен ли обработчик команд принимать входящую команду и в результате публиковать событие.
Таким образом, единственные поля, которые вы должны ввести в свой агрегат вместе с агрегатным идентификатором, - это поля, необходимые для принятия этих решений. Это то, для чего предназначена модель команд, поэтому не беспокойтесь об этом.
Чтобы ответить на любые запросы в вашем приложении, вы должны ввести специальную модель запроса, которая обновляется в результате событий, опубликованных обработчиками команд в Aggregate. Именно это точное разделение является сильной стороной этой модели, поскольку она обеспечивает лучшее масштабирование, повышение производительности или необходимое разделение команд среди других нефункциональных требований.
person
Steven
schedule
23.10.2019
