Предпочтительный способ обработки «Event Sourcing» в рецепте NestJS CQRS - PullRequest
Новая
       20

Предпочтительный способ обработки «Event Sourcing» в рецепте NestJS CQRS

0 голосов
/ 23 декабря 2018

Я пытаюсь найти предпочтительный способ выполнения «Event Sourcing» при использовании рецепта NestJS CQRS (https://docs.nestjs.com/recipes/cqrs).

Я смотрел на среду NestJS в течение последних нескольких недельи люблю все его аспекты. За исключением документов, которые в некоторых областях довольно тонкие.

Либо у NestJS нет собственного мнения о том, как реализовать "Event Sourcing", либо я что-то упускаюочевидно.

Мой главный вопрос - какой самый простой способ сохранить сами события?

Сейчас мои события выглядят довольно простыми: 

import { IEvent } from '@nestjs/cqrs';

export class BookingChangedTitleEvent implements IEvent {
    constructor(
        public readonly bookingId: string,
        public readonly title: string) {}
}

Моя первоначальная идея былаиспользовать TypeORM (https://docs.nestjs.com/recipes/sql-typeorm) и заставить каждое из моих событий не только реализовать IEvent, но и заставить его наследовать TypeORM @Entity().

Но это будет иметь одну таблицу (SQL) илисборник (NoSQL) для каждого из событий, что делает невозможным чтение всех событий, которые произошли с одним агрегатом. Я что-то упустил?

Другой подход - сбросить каждое событие в JSON, что звучит довольно легко.Но как мне тогда загрузить объектные IEvent классы из БД?(звучит так, как будто я внедряю свой собственный ORM)

Ответы [ 2 ]

0 голосов
/ 11 июля 2019

Я уверен, что это будет сильно отличаться в зависимости от уровня сохраняемости.При использовании MongoDB у меня есть свободные схемы событий с Mongoose, с некоторыми обязательными свойствами для агрегатных событий.

Сами события являются просто простыми классами, такими как: 

class FooHappened {
  constructor(
    readonly root: string;
    readonly bar: string;
  ) {}
}

Я использовалroot свойство для совокупного корня ObjectId для построения моделей чтения, которое до сих пор работало хорошо.

0 голосов
/ 28 декабря 2018

Итак, я делаю что-то подобное и использую postgres, который поддерживает поддержку json ('simple-json') в родном языке TypeORM ( ссылка ).Хорошо это или плохо, но моя сущность события выглядит так: 

@Entity()
export class MyEvent {
  @PrimaryGeneratedColumn('uuid')
  id: string;

  @Column()
  name: string;

  @Column('simple-json')
  data: object;

  @CreateDateColumn({type: 'timestamp'})
  created_at: Date;
}

Важно отметить, что я использую только свои постоянные события для контрольного журнала и гибкость потенциальных прогнозов, которые я еще не строю.Вы можете абсолютно запросить JSON в postgres, используя TypeORM, например..where('my_event.data ::jsonb @> :data', {data: {someDataField: 2}}), но, насколько я понимаю, запросы на ваши события, чтобы узнать текущее состояние, как бы упускают из виду CQRS.Лучше создать агрегаты в новых таблицах прогнозов или обновить один огромный прогноз.

Я в порядке с тем, как я в настоящее время продолжаю свои события, но это, конечно, не СУХОЙ.Я бы подумал, что расширение базового класса с помощью обычного saveEvent метода или использование класса EventHandlerFactory, который будет принимать репозиторий в своем конструкторе, будет немного чище, чем внедрение репозитория в каждый обработчик.

Может, у кого-то есть хорошие мысли?

...