Мотивация

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

Часто, студенты или стажёры, приходя к нам в команду не могут понять ни что такое CQRS, ни тем более как и причём тут NestJS.

Также, у нас в команде, по умолчанию, начиная с самых младших рангов я начинаю учить внедрению и использованию DDD, а так как aggregates работает на базе Event Sourcing, то и про него тут пойдёт речь.

Вместо того, чтобы копипастить по кругу одно и то же в рамках гитхаба, я решил собрать немного все эти ответы и сформировать небольшой пост-заметку-шпаргалку, о том, как это вообще всё устроено. Максимально простым языком, без углублений, просто и понятно.

Вопросы

И так рассмотрим основные (читай "часто задаваемые") вопросы:

• За что отвечает каждый паттерн cqrs внутри доменной модели?

• Как работает event sourcing внутри модуля?

• Как работает event sourcing с базой данных?

• Как работает event sourcing в nest js?

Также, я решил не лишним использовать футбольные и строительные метафоры, для большего понимания. Однако, если кому-то это покажется непонятным или не правильным - напишите в комментах и я с радостью напишу ещё несколько постов на эту тему.

CQRS

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

И так CQRS (Command Query Responsibility Segregation) - это как если бы в футбольной команде у каждого игрока была своя роль. Нападающие (Commands) набирают очки, а защитники (Queries) предотвращают забивание голов. Каждый делает свою работу, и это помогает команде работать более эффективно.

В терминах CQRS:

• Command - это нападающий, который создаёт изменения. Это действия, которые изменяют состояние системы, например, создание нового пользователя.

• Query - это защитник, который получает информацию. Это запросы, которые возвращают данные, но не меняют состояние системы.

Event Sourcing

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

Внутри модуля, Event Sourcing работает как ведущий строитель. Когда ты строишь дом, ты начинаешь с фундамента, потом стены, затем крышу. Каждый шаг зависит от предыдущего. В Event Sourcing, каждое событие (например, "пользователь создан", "пароль изменён") изменяет состояние системы. Приложение "строится", применяя каждое событие по порядку.

В контексте работы с базой данных, Event Sourcing - это как строитель, который хранит все чертежи и планы. Вместо того, чтобы просто хранить текущее состояние дома, он хранит каждый план, каждое изменение, которое было сделано. Это означает, что можно отследить каждое изменение, которое было сделано, и даже "отмотать назад", чтобы увидеть, как выглядел дом в прошлом.

NestJS Event Sourcing

NestJS поддерживает Event Sourcing через свою библиотеку CQRS. Это как если бы тренер команды дал игрокам стратегию, которую они должны следовать. NestJS предоставляет структуру и инструменты (такие как декораторы и модули), которые помогают организовать твой код вокруг концепций CQRS и Event Sourcing.

P.S: Это моя первая "около-техническая" статья, поэтому прошу сильно не бомбить. Статью писал на коленке, в качестве наглядного пособия для своих ребятишек, в будущем обещаюсь запаблить репозиторий с примерами кода. Всем Мир.