Какие знаешь виды архитектур?

Виды архитектур приложений: Практический обзор

Виды архитектур — это различные способы структурировать приложение. За 10+ лет я работал почти со всеми из них и вижу плюсы/минусы каждой не только в теории, но и на практике. Расскажу о самых важных архитектурах, которые встречаются в реальных проектах.

1. Монолитная архитектура (Monolithic)

Структура:

┌─────────────────────────────────┐
│       Web Application            │
│  ┌──────────┬──────────┐         │
│  │ Auth     │ Products │         │
│  ├──────────┼──────────┤         │
│  │ Orders   │ Payments │         │
│  └──────────┴──────────┘         │
└─────────────────────────────────┘
        ↓
    [Database]

Всё в одном приложении, одна база данных, один сервер.

Плюсы:

• Простая разработка в начале (все в одном месте)
• Транзакции просты (один вызов функции, все работает атомарно)
• Нет сетевых задержек между компонентами
• Легко развернуть (один сервер)
• Просто отлаживать (всё в одном стеке)

Минусы:

• Сложно масштабировать (нельзя масштабировать отдельный компонент)
• Один баг в Orders может рушить весь сервис
• Сложно разрабатывать параллельно (много merge conflicts)
• Трудно обновить одну часть без риска сломать другую
• Один downtime = весь сервис down

Когда использовать:

• Стартап с <5 разработчиков
• MVP (minimum viable product)
• Нет требований к масштабированию на год

Примеры: WordPress, простой CRUD приложение, админ-панель

2. Микросервисная архитектура (Microservices)

Структура:

    API Gateway (entry point)
        ↙  ↓  ↘
    ┌────┬────┬────┐
    │    │    │    │
  [Auth] [Orders] [Payments]
   Service Service  Service
    │      │        │
  [DB]   [DB]     [DB]

Каждый сервис независим, имеет свою БД, API.

Плюсы:

• Масштабируемость (запусти N копий Orders Service)
• Независимость (Orders Service может быть down, остальное работает)
• Параллельная разработка (разные команды работают независимо)
• Обновления без downtime (blue-green deployment)
• Гибкость в tech stack (один на Python, другой на Go)

Минусы:

• Сложность распределённых систем (сетевые задержки, race conditions)
• Трудно тестировать (интеграционные тесты сложные)
• Трудно отлаживать (логи в разных сервисах)
• Операционная сложность (нужна оркестрация: Docker, Kubernetes)
• Data consistency сложнее (saga pattern, eventual consistency)
• Дороже в разработке и инфраструктуре

Когда использовать:

• Масштабирующееся приложение (100K+ пользователей)
• Большая команда (>20 разработчиков)
• Разные части имеют разные требования (Orders быстрый, Analytics медленный)

Примеры: Netflix, Amazon, Uber (все эти компании используют микросервисы)

3. Слойная архитектура (Layered / N-tier)

Структура:

┌──────────────────────────┐
│  Presentation Layer      │  (REST API, GraphQL, Web UI)
│  (Controllers, Views)    │
└──────────┬───────────────┘
           ↓
┌──────────────────────────┐
│  Business Logic Layer    │  (Use cases, validation)
│  (Services, Validators)  │
└──────────┬───────────────┘
           ↓
┌──────────────────────────┐
│  Data Access Layer       │  (ORM, Queries)
│  (Repositories)          │
└──────────┬───────────────┘
           ↓
┌──────────────────────────┐
│  Database Layer          │  (PostgreSQL, MongoDB)
└──────────────────────────┘

Приложение разделено горизонтально по слоям.

Плюсы:

• Понятная структура (каждый слой имеет одну ответственность)
• Легко тестировать (можешь тестировать business logic без БД)
• Разделение ответственности (тесты пишут разные люди на разных слоях)
• Масштабируемость in width (добавить сервер)

Минусы:

• Масштабируемость in depth сложная (если business logic делает много БД запросов)
• "Fat controller" проблема (логика утекает в контроллеры)
• N+1 problem (많은 запросы к БД вместо одного)
• Изменения могут затронуть много слоёв

Когда использовать:

• Традиционные приложения (CRM, ERP, админ-панель)
• CRUD приложение
• Стандартная архитектура

Примеры: Django приложение, Spring Boot приложение (обычно)

4. Hexagonal архитектура (Ports & Adapters)

Структура:

        API Adapter          DB Adapter
          ↓                    ↓
    ┌──────────────┐
    │              │
    │  Core Logic  │  (Domain, Use cases)
    │  (Hexagon)   │
    │              │
    └──────────────┘
          ↓
      Queue Adapter

Ядро (core logic) отделено от адаптеров (способы общения с миром).

Плюсы:

• Ядро не зависит от технологий (можно менять БД, API фреймворк)
• Легко тестировать (mock'и для адаптеров)
• Гибкость (разные адаптеры для разных клиентов)

Минусы:

• Сложнее понять архитектуру (более abstract)
• Больше кода (много adapter interfaces)
• Overkill для простых приложений

Когда использовать:

• Долгоживущий проект (5+ лет)
• Требует частых изменений в технологиях
• Clean architecture important

5. Event-driven архитектура

Структура:

Order Service публикует "OrderCreated" event
           ↓
   Message Queue (Kafka, RabbitMQ)
           ↓
    ┌──────┴──────┬──────────┐
    ↓             ↓          ↓
[Notification] [Analytics] [Inventory]
 Service      Service    Service

Сервисы общаются через события, не синхронные вызовы.

Плюсы:

• Слабая связанность (loose coupling)
• Масштабируемость (async обработка)
• Resilience (если один consumer down, очередь хранит события)
• Гибкость (добавить новый consumer легко)

Минусы:

• Eventual consistency (данные обновляются не сразу)
• Трудно отлаживать (события распределены)
• Guarantees доставки сложнее (at-least-once, exactly-once)

Когда использовать:

• Real-time системы (notifications, analytics)
• Высокие нагрузки
• Асинхронная обработка важна

Примеры: Notifications service, Real-time analytics

6. DDD (Domain-Driven Design)

Концепция: Архитектура строится вокруг бизнес-домена, не технологии.

Слои:

┌─────────────────────┐
│ Interface Layer    │  (API endpoints)
├─────────────────────┤
│ Application Layer  │  (Use cases, orchestration)
├─────────────────────┤
│ Domain Layer       │  (Business logic, entities)
├─────────────────────┤
│ Infrastructure     │  (Database, external APIs)
└─────────────────────┘

Плюсы:

• Фокус на бизнес-логику
• Domain experts и разработчики говорят на одном языке
• Чистая архитектура
• Легко тестировать domain layer

Минусы:

• Сложно для простых приложений
• Требует глубокого понимания domain
• Больше кода

Когда использовать:

• Сложный бизнес-домен
• Долгосрочный проект
• Высокие требования к quality

7. CQRS (Command Query Responsibility Segregation)

Идея: Отделить операции чтения от операций записи.

Структура:

Client
  ├─ Write Request (Command) → Write Model → Master DB
  └─ Read Request (Query) → Read Model → Replica DB

Плюсы:

• Оптимизация (разные модели для чтения и записи)
• Масштабируемость (масштабировать чтение и запись отдельно)
• Асинхронность (read model может обновляться асинхронно)

Минусы:

• Сложность (eventual consistency)
• Оverkill для простых CRUD приложений

Когда использовать:

• Комплексные системы с high load
• Разные требования к чтению/записи

8. Serverless архитектура

Концепция: Не управляешь серверами, только функциями.

Структура:

Client → API Gateway → Lambda Functions → Database

Каждый endpoint это отдельная функция, которая запускается по требованию.

Плюсы:

• Масштабируемость (auto-scaling)
• Низкие затраты (платишь за что используешь)
• Быстрое развёртывание
• Управления infrastructure нет

Минусы:

• Cold start (первый запрос медленнее)
• Vendor lock-in (AWS Lambda, Google Functions)
• Сложнее отлаживать локально
• Статическое состояние (нельзя хранить в памяти между запросами)

Когда использовать:

• API с переменной нагрузкой
• Микротаски (обработка фотографии, отправка email)
• MVP (быстрое развёртывание)

Примеры: AWS Lambda, Google Cloud Functions

Сравнительная таблица

Архитектура    | Сложность | Масштаб | Стоимость | Dev Speed
────────────────┼───────────┼─────────┼──────────┼──────────
Монолит        | Низкая    | Низкий  | Низкая   | Высокая
Микросервисы   | Высокая   | Высокий | Высокая  | Средняя
Layered        | Средняя   | Средний | Средняя  | Высокая
Hexagonal      | Высокая   | Средний | Средняя  | Средняя
Event-driven   | Высокая   | Высокий | Высокая  | Средняя
Serverless     | Средняя   | Высокий | Низкая*  | Высокая

• Низкая при переменной нагрузке, может быть дорога при constant high load

Как я выбираю архитектуру

Вопросы, которые я задаю:

1. Размер и рост: Сколько пользователей сейчас? Сколько ожидаем через год?

   • < 100K users → Монолит или Layered

   • 100K users → Микросервисы или Event-driven

2. Размер команды: Сколько разработчиков?

   • < 10 → Монолит
   • 10-30 → Microservices или DDD

   • 30 → Microservices with CQRS

3. Требования к надёжности: Может ли сервис быть down на 1 час?

   • Yes → Монолит, Layered
   • No → Microservices, Event-driven

4. Требования к скорости разработки: Нужно быстро?

   • Yes → Монолит, Serverless
   • No → DDD, Hexagonal (долгосрочный инвестирование)

5. Требования к надёжности данных: Нужны ACID транзакции?

   • Yes → Монолит, Layered, DDD
   • No → Event-driven, Microservices

Пример: Как я бы проектировал SaaS платформу

День 1 (MVP): Монолит (Python Django + PostgreSQL). Всё быстро, просто.

3 месяца (10K пользователей): Всё ещё монолит. Добавим кэш (Redis) для оптимизации.

1 год (100K пользователей): Начинаем думать о микросервисах:

• Auth Service (критичный, нужна отдельная масштабируемость)
• API Service (остальная логика)
• Analytics Service (асинхронная обработка)

2 года (500K пользователей): Полные микросервисы:

• Auth Service
• User Service
• Product Service
• Order Service
• Payment Service
• Notification Service
• Analytics Service (event-driven)

Результат правильной архитектуры

• Скорость разработки соответствует масштабу
• Надёжность соответствует требованиям
• Затраты оптимальны
• Возможность масштабирования есть когда надо
• Счастливая команда (архитектура не мешает работе)

Ключевое правило: Не overengineer рано. Начни с простого, рефакторь когда нужно.