CQRS aggregates

Question

Я новичок в мире CQRS/ES, и у меня есть вопрос. Я работаю над веб-приложением для выставления счетов, которое использует источники событий и CQRS.

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

То, что я не совсем понял, это то, как я могу сохранить этот агрегат в памяти для начала, прежде чем пытаться применить команду. Если у меня есть миллион счетов-фактур в системе, должен ли я воспроизводить всю историю каждый раз, когда я хочу применить команду? Всегда ли я сохраняю событие без каких-либо проверок и выполняю проверки при построении моделей/прогнозов?

Если я неправильно понял какую-либо часть процесса, я был бы признателен за ваши отзывы.

Благодарим за помощь!

Answer 1

Вы не одиноки, это распространенное недоразумение. Позвольте мне сначала ответить на часть валидации:

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

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

Следующий этап заключается в том, чтобы домен применял изменение состояния и увеличивал связанные события. Затем они сохраняются и на успех, публикуются для остальной части приложения.

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

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

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

Если вы хотите узнать больше, посмотрите мой обзор CQRS и ES here. И взгляните на мой пост о том, как построить совокупные корни here.

Удачи - надеюсь, они помогут!

Answer 2

Правильно, что вам нужно воспроизвести событие, чтобы «регидратировать» совокупность доменов. Но вам не нужно воспроизводить все события для всех счетов-фактур.Если вы храните идентификатор объекта корневой совокупности в событиях, вы можете просто выбрать и воспроизвести события, имеющие соответствующий идентификатор.

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