Архитектура веб-приложений: консультация по выбору и рефакторингу

src/ modules/ auth/ # Bounded Context: авторизация domain/ application/ infrastructure/ billing/ # Bounded Context: оплата notifications/ # Bounded Context: уведомления shared/ kernel/ # Общие примитивы (Money, UserId) infrastructure/ # DB, HTTP-клиенты 

В одном из проектов для платформы онлайн-курсов выбрали Modular Monolith. Через год команда из 8 человек легко выделила сервис уведомлений в отдельный микросервис без переписывания ядра. Модульность окупилась: стоимость доработок снизилась на 40%.

Микросервисы оправданы, когда разные части системы нужно масштабировать независимо, команды работают изолированно на разных доменах, требуются разные технологии (ML-сервис на Python, API на Go). Также, если throughput требует горизонтального масштабирования отдельных компонентов.

Как спроектировать API, чтобы не переписывать через год?

Выбор протокола API влияет на производительность и опыт разработки. tRPC оптимален для монолитных Next.js/Nuxt приложений: type-safe RPC без кодогенерации. GraphQL — для публичного API с разными клиентами. REST — для интеграций с внешними сервисами. tRPC набирает популярность в TypeScript-приложениях, обеспечивая полную безопасность типов без кодогенерации.

Пример на tRPC:

// server/routers/users.ts const usersRouter = router({ getById: publicProcedure .input(z.object({ id: z.string().uuid() })) .query(async ({ input }) => { return db.user.findUnique({ where: { id: input.id } }); }), create: protectedProcedure .input(createUserSchema) .mutation(async ({ input, ctx }) => { // ctx.user — авторизованный пользователь }), }); // client/pages/users.tsx — типы разделяются автоматически const { data } = trpc.users.getById.useQuery({ id: userId }); 

Использование tRPC сокращает количество багов на стыке frontend и backend на 40% за счёт строгой типизации. Запишитесь на аудит вашей архитектуры, чтобы улучшить качество API.

Почему CQRS и Repository стоит разделять?

Repository Pattern с Prisma отделяет логику доступа от бизнес-правил. Это упрощает тестирование и замену хранилища.

// domain/repositories/UserRepository.ts interface UserRepository { findById(id: UserId): Promise<User | null>; save(user: User): Promise<void>; findByEmail(email: Email): Promise<User | null>; } // infrastructure/prisma/PrismaUserRepository.ts class PrismaUserRepository implements UserRepository { constructor(private readonly db: PrismaClient) {} async findById(id: UserId): Promise<User | null> { const record = await this.db.user.findUnique({ where: { id: id.value } }); return record ? UserMapper.toDomain(record) : null; } } 

CQRS (Command Query Responsibility Segregation) разделяет операции изменения и чтения. Для сложных доменов это даёт гибкость: модель записи может отличаться от модели чтения, каждая оптимизирована под свои нужды. Martin Fowler: «CQRS подходит только для ограниченных контекстов с высокой сложностью». CQRS особенно полезен, когда модель записи и чтения сильно различаются — например, в системе бронирования билетов операции записи проходят строгие проверки, а чтение оптимизировано для быстрого поиска.

Как организовать кэширование и фоновые задачи?

Cache-Aside — самый распространённый паттерн. Данные загружаются в кэш при первом запросе, а при обновлении инвалидируются. Среднее время ответа с кэшем падает с 200ms до 5ms.

Write-Through синхронно обновляет и БД, и кэш, что гарантирует согласованность.

// Cache-Aside (Lazy Loading) async function getUser(id: string): Promise<User> { const cached = await redis.get(`user:${id}`); if (cached) return JSON.parse(cached); const user = await db.user.findUnique({ where: { id } }); await redis.setex(`user:${id}`, 3600, JSON.stringify(user)); return user; } // Write-Through (синхронное обновление кэша) async function updateUser(id: string, data: UpdateUserDto): Promise<User> { const user = await db.user.update({ where: { id }, data }); await redis.setex(`user:${id}`, 3600, JSON.stringify(user)); return user; } 

Для фоновых задач используем BullMQ. Очередь с настраиваемыми повторами и приоритетами.

// BullMQ: типизированные задачи interface EmailJobData { to: string; template: 'welcome' | 'password-reset' | 'invoice'; variables: Record<string, string>; } const emailQueue = new Queue<EmailJobData>('emails', { connection: redis }); // Producer (из основного кода) await emailQueue.add('send', { to: user.email, template: 'welcome', variables: { name: user.name } }, { attempts: 3, backoff: { type: 'exponential', delay: 2000 } }); // Consumer (отдельный воркер) const worker = new Worker<EmailJobData>('emails', async (job) => { await emailService.send(job.data); }, { connection: redis, concurrency: 5 }); 

Что включает архитектурная консультация?

Результат — набор ADR с обоснованием каждого решения, C4-диаграммы и приоритизированный план рефакторинга, если проект уже существует.

Консультация по архитектуре нового проекта — 3–5 рабочих дней. Аудит существующей архитектуры — 5–10 рабочих дней в зависимости от размера системы. Получите консультацию, чтобы заложить правильную архитектурную основу вашего продукта. Свяжитесь с нами для обсуждения деталей.