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

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 рабочих дней в зависимости от размера системы. Получите консультацию, чтобы заложить правильную архитектурную основу вашего продукта. Свяжитесь с нами для обсуждения деталей.