Когда стоит использовать монолитную архитектуру?

Когда использовать монолитную архитектуру

Монолит — классический подход, проверенный временем. Это первый выбор для большинства проектов, и только со временем нужно переходить на альтернативы.

1. Начальный этап проекта / MVP

Монолит позволяет быстро вывести продукт на рынок:

// Простая структура
shop-application/
├── src/
│   ├── users/
│   │   ├── UserController.java
│   │   ├── UserService.java
│   │   └── User.java
│   ├── products/
│   │   ├── ProductController.java
│   │   ├── ProductService.java
│   │   └── Product.java
│   └── orders/
│       ├── OrderController.java
│       ├── OrderService.java
│       └── Order.java
└── pom.xml

Преимущества:

• Разработка идёт быстро
• Легко шарить код между модулями
• Простая отладка
• Лёгкое развёртывание

2. Маленькая или средняя команда

Освобождает разработчиков от overhead архитектуры:

Монолит (5 разработчиков):
- Один git репозиторий
- Общее понимание архитектуры
- Один backlog
- Синхронный коммит

Микросервисы (5 разработчиков):
- 5+ репозиториев
- Каждый разработчик в своём сервисе
- Версионирование API

3. Требования ещё не стабилизировались

Монолит позволяет быстро рефакторить без миграции:

// Было
@RestController
public class OrderController {
    @PostMapping("/orders")
    public Order createOrder(OrderRequest request) { }
}

// Стало (просто переименовал)
@RestController
public class OrderController {
    @PostMapping("/api/v1/orders")
    public OrderResponse createOrder(@RequestBody CreateOrderCommand cmd) { }
}

4. Необходимы ACID транзакции

Монолит гарантирует консистентность данных:

// Банковское приложение
@Service
public class MoneyTransferService {
    @Transactional
    public void transfer(String from, String to, BigDecimal amount) {
        // Весь блок — атомарная операция
        Account sender = accounts.findById(from);
        Account receiver = accounts.findById(to);
        
        sender.setBalance(sender.getBalance().subtract(amount));
        receiver.setBalance(receiver.getBalance().add(amount));
        
        // Если ошибка — всё откатится
    }
}

С микросервисами нужна распределённая транзакция (Saga) — сложно и ненадёжно.

5. Доменные границы чётко определены

Монолит хорошо работает с модульной архитектурой:

src/
├── user-domain/
│   ├── entity/
│   ├── repository/
│   ├── service/
│   └── event/
├── order-domain/
│   ├── entity/
│   ├── repository/
│   ├── service/
│   └── event/
└── shared/
    ├── event/
    └── exception/

6. Нагрузка умеренная

Для большинства приложений нагрузка не требует микросервисов:

Типичная нагрузка:
- E-commerce: 100-500 RPS
- SaaS: 50-200 RPS
- Корпоративный портал: 10-50 RPS

Монолит справляется отлично:
- Modern JVM: 1000+ RPS на стандартном железе
- Масштабирование: несколько инстансов + load balancer

7. Данные сильно интегрированы

Едина база данных — преимущество:

// Легко писать сложные запросы
public List<UserWithOrders> getUsersWithOrders() {
    return em.createQuery(
        "SELECT new com.shop.UserWithOrders(u, COUNT(o)) " +
        "FROM User u LEFT JOIN u.orders o " +
        "GROUP BY u.id",
        UserWithOrders.class
    ).getResultList();
}

С микросервисами: вызвать каждый сервис → объединить данные → медленно (N+1).

8. Команда не имеет опыта DevOps

Монолит не требует продвинутой инфраструктуры:

Монолит:
✓ git + CI/CD
✓ одна база данных
✓ стандартный мониторинг

Микросервисы:
✓ Kubernetes
✓ Service discovery
✓ Distributed tracing
✓ Centralized logging (ELK)
✓ API Gateway
✓ Message broker

Путь развития

Монолит
  ↓ (когда вырастет)
Модульный монолит
  ↓ (чёткие границы)
Микросервисы
  ↓ (максимальная масштабируемость)
Serverless / Event-driven

Вывод

Начни с монолита. Это правильный выбор в 95% случаев. Переходи на микросервисы только когда:

• Команда вырастет до 15+ человек
• Разные части требуют разного масштабирования
• Инфраструктура готова
• Требования стабилизировались

Помни: монолит прост, быстр и надёжен. KISS принцип работает.