🧩 От событий к коду: как я проектирую волейбольный агрегатор через Event Storming и DDD

Разбор архитектуры Telegram-сервиса для волейбольных игр: от сценариев пользователей до транзакций и агрегатов в коде.

Я создаю Telegram-сервис для волейбольного сообщества города. Игроки ищут ближайшие игры, записываются, получают напоминания и отмечают оплату. Организаторы управляют наборами и видят статусы участников.

На этапе MVP в системе только: — Telegram-бот — сервер с бизнес-логикой — база данных

Чтобы не превратить MVP в хаос эндпоинтов, я пошёл по пути Event Storming + Domain-Driven Design (DDD).

Event Storming помогает не «рисовать базы», а думать событиями: «Игра создана», «Игрок записался», «Игра началась», «Оплата отмечена».

Так проще увидеть реальные процессы, а не только таблицы.

Цель: описать систему глазами игроков, организаторов и системы напоминаний.

Основные контексты:

Жизненный цикл событий: GameCreated → PlayerJoined → WaitlistedPromoted → GameStarted → PaymentMarked

Бизнес-правила (policies):
• OnGameCreated → ScheduleReminders (24ч, 2ч)
• OnRegistrationCanceled → PromoteWaitlisted
• OnGameStarted → OpenPaymentWindow
• OnCapacityReached → BlockNewJoins

Когда поведение стало понятным, я описал доменную модель с агрегатами, инвариантами и use-cases.

Game (корневой агрегат): — контролирует вместимость, статусы, время начала и окно оплаты — инварианты:
• capacity > confirmedCount
• startsAt > now()
• status ∈ {open, closed, finished, canceled}

Registration: — описывает участие игрока — инварианты: уникальность (gameId, userId), допустимые переходы, оплата только после старта

joinGame() — записывает игрока, проверяет лимит и уникальность

leaveGame() — отменяет участие и продвигает первого из листа ожидания. markPayment() — работает только после начала игры (now ≥ startsAt).

Чтобы исключить гонки:

Для идемпотентности — ключ событий: evt:<type>:<gameId>:<userId>:<bucket>

Game: id, organizerId, startsAt, capacity, status, registrations[]

Registration: id, gameId, userId, status (confirmed / waitlisted / canceled), paymentStatus (unpaid / paid)

Гонки на последнем месте: транзакции + advisory lock Повторные клики: идемпотентность Ошибки Telegram: retry + логирование Несинхронное время: всё в UTC

Технологии: — Node.js + TypeScript — Fastify (API) — Prisma ORM + PostgreSQL — Redis + BullMQ (уведомления) — Sentry (ошибки)

Слои:

Event Storming позволил увидеть систему глазами игроков, а Domain-Driven Design превратил это понимание в устойчивую архитектуру.

Когда система растёт из событий, а не из таблиц — она естественно масштабируется и остаётся управляемой.

📎 Подробные схемы Event Storming и Domain Model есть в репозитории: