Источники событий Nestjs - постоянство событий

В документации говорится: Для упрощения модели [CQRS] Nest предоставляет облегченный модуль CQRS., и это именно то, что он предлагает. В отличие от остальной части NestJS, небольшая объектная модель cqrs не настолько самоуверенна, что оставляет множество архитектурных решений для разработчика.

Таким образом, объектная модель позволяет чистым способом создавать объекты Command, Saga, Query и Event и предоставлять для них обработчики, определять AggregateRoot сущности и иметь шины сообщений для публикации, но не более того. Оставляя вас с основами для создания дизайна, ориентированного на предметную область.

Как вы их интегрируете, зависит только от вас. Если вы выполните поиск по Github по запросу "nest + cqrs", вы найдете много разных подходов. . Некоторые варианты, например:

• Создавайте команды непосредственно в контроллерах, а не в службах уровня приложений.
• Команды не возвращают данных, а возвращают только ошибки или возвращают данные только для записи.
• Совокупный корень и сущность DB / ORM - это один и тот же класс (не лучшая практика DDD).
• События, генерируемые вручную через шину событий, а не из совокупного корня через mergeObjectContext.
• Единая база данных для моделей со стороны чтения и записи по сравнению с несколькими базами данных.

Ваш вопрос о сохраняющихся событиях относится к последнему пункту и намекает на реализацию Event Sourcing (ES) поверх CQRS. Обратите внимание, что это совершенно необязательно. Хотя ES поставляется с множеством интересных функций, вам следует применять этот шаблон только в том случае, если этого требуют требования вашего приложения. ES имеет дополнительную сложность, которую нельзя недооценивать. Так что определенно рекомендуется ознакомиться с плюсами и минусами (cqrs.nu FAQ - хорошее начало). Обратите внимание, что вы можете просто реализовать CQRS и добавить ES позже, когда возникнет необходимость.

Таким образом, поиск событий (и сохранение событий) не являются частью модуля NestJS CQRS. Когда вы решите сохранить свои события, вы можете использовать специализированную базу данных, такую ​​как Eventstore, или реализовать ее в своей реляционной базе данных ( см. для Postgres, например, Хранилище событий в Postgres, Источник событий PostgreSQL или полномасштабный проект message-db).

С Event Sourcing ваша настройка может выглядеть так, как описано в хорошей статье Event-Sourcing с NestJS от Элирана Натана:

В этой настройке вы должны сделать проекции для загрузки - обычно - реляционной БД с денормализованными представлениями для стороны чтения вашей архитектуры. Без ES это может не понадобиться, и вы можете использовать ORM или прямые SQL-запросы для наполнения ваших Query объектов соответствующими данными.

Вот и все. Последний совет: никогда не обращайтесь напрямую к логике на стороне чтения из кода на стороне записи (рецепт проблемы, поскольку он разрушает разделение команд и запросов).