Архітектура веб-додатків: консультація з вибору та рефакторингу

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