Для чего нужна монолитная архитектура?

# Монолитная архитектура: назначение, преимущества и недостатки

Монолитная архитектура — это подход, при котором всё приложение строится как один единый, неделимый блок кода. Все компоненты (UI, бизнес-логика, база данных) тесно интегрированы в одно целое и развёртываются вместе.

Структура монолитного приложения

Monolithic App
├── Controllers Layer (REST API)
├── Service Layer (Бизнес-логика)
├── Repository Layer (Доступ к данным)
├── Domain Models
├── Utilities & Helpers
└── Database (PostgreSQL)

# Всё развёртывается как один артефакт (JAR/WAR)

Основное назначение и преимущества

1. Простота разработки и развёртывания

// Монолит просто в разработке
// Одна codebse, одна база данных, один контекст

pom.xml содержит все зависимости
mvn clean package → один JAR файл
java -jar app.jar → всё работает

// Против microservices, где нужно координировать 10+ сервисов

2. Высокая производительность

Внутри-процессные вызовы значительно быстрее, чем сетевые:

// Монолит — быстро
@Service
public class OrderService {
    @Autowired
    private PaymentService paymentService; // In-process call
    
    public void createOrder(Order order) {
        // Прямой вызов метода в памяти
        paymentService.processPayment(order); // ~1ms
    }
}

// Microservices — медленнее
// REST call: OrderService → PaymentService
// Network latency + serialization + deserialization: ~100-300ms

3. Простота отладки

// Один стек вызовов, одна БД, один лог файл
// Проще отследить проблему

// Exception stack trace видит всю цепочку:
OrderController.createOrder()
  → OrderService.processOrder()
    → PaymentService.processPayment()
      → PaymentRepository.save()
        → Database error

4. Простота общего состояния приложения

// Монолит — легко делиться состоянием
@Service
public class CacheService {
    private Cache<String, Data> cache = new HashMap<>(); // Общий кэш
    
    public Data getCached(String key) {
        return cache.get(key); // Все потоки видят один кэш
    }
}

// Все компоненты в одном процессе имеют доступ
// Легко использовать singleton кэши, сессии и т.д.

5. Транзакции БД

// ACID транзакции просто работают
@Transactional
public void transferMoney(Account from, Account to, BigDecimal amount) {
    from.debit(amount);
    to.credit(amount);
    // Или всё коммитит, или всё откатывает
    // Никаких distributed transactions
}

6. Меньше сложности в начале проекта

// Новый startup — монолит быстрее написать

// Неделя разработки: App работает
// VS Microservices:
// - Неделя на инфраструктуру
// - Неделя на синхронизацию между сервисами
// - Неделя на monitoring и logging

Недостатки монолитной архитектуры

1. Сложность масштабирования

// Проблема: если нужна 10x масштабируемость
// Нельзя масштабировать отдельные компоненты

// Монолит — масштабируем всё целиком
// 3 инстанса приложения × 3 БД = сложность

public class PaymentService { // Требует 10x масштабирования
    // но OrderService, UserService масштабируются нормально
}

// Если приложение 100 MB, а PaymentService = 2MB
// Каждый инстанс содержит 98 MB ненужного кода

2. Сложность разработки при росте

// Монолит на 500k строк кода:
// - Сложная навигация
// - Высокий coupling между модулями
// - Конфликты в версиях зависимостей
// - Долгие сборки (5-10 минут)

// При развёртывании:
// - Риск: малое изменение → весь монолит ломается
// - Нельзя развернуть только PaymentService
// - Все разработчики конкурируют за одну кодовую базу

3. Технологическая зависимость

// Весь монолит на Java/Spring
// Хотим добавить Python ML сервис?
// Хотим использовать Go для обработки событий?

// Нельзя просто добавить другой язык
// Microservices позволяют использовать разные технологии

4. Независимое развёртывание невозможно

// Чтобы исправить баг в PaymentService
// Нужно перестартовать всё приложение
// включая OrderService и UserService
// В процессе стартапа все пользователи испытывают downtime

// Microservices:
// Обновляем PaymentService
// OrderService работает как и раньше
// Downtime = 0

5. Сложность при teamwork

// 50 разработчиков в одном монолите
// - Долгое время на merge
// - Конфликты в коде
// - Slow deployments (ждём когда все обновят кодовую базу)

// Microservices:
// Team A → PaymentService (5 разработчиков)
// Team B → OrderService (5 разработчиков)
// Независимо разрабатывают и деплоят

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

✅ Стартапы и новые проекты — быстро вывести MVP ✅ Маленькие команды — 5-10 разработчиков ✅ Внутренние системы — не требующие 99.99% uptime ✅ Простые приложения — CRUD операции, низкая нагрузка ✅ Высокие требования к latency — внутри-процессные вызовы ✅ Сложные транзакции — ACID requirement

Когда НЕ использовать монолит

❌ Большой масштаб — миллионы пользователей ❌ Высокие требования к scalability — нужна независимая масштабируемость компонентов ❌ Большая команда — 50+ разработчиков ❌ Разные технологии — нужны Python, Go, Node.js, Java ❌ Быстрое развёртывание — нужен часто деплоить ❌ Независимые компоненты — платежи, аналитика, рекомендации

Пример монолитного приложения Spring Boot

// Полное приложение в одном проекте

pom.xml
├── spring-boot-starter-web
├── spring-boot-starter-data-jpa
├── postgresql driver
└── jackson (JSON)

src/main/java/
├── com.example.api
│   ├── UserController.java
│   ├── OrderController.java
│   └── PaymentController.java
├── com.example.service
│   ├── UserService.java
│   ├── OrderService.java
│   └── PaymentService.java
├── com.example.repository
│   ├── UserRepository.java
│   ├── OrderRepository.java
│   └── PaymentRepository.java
└── com.example.domain
    ├── User.java
    ├── Order.java
    └── Payment.java

# Один JAR файл: app.jar (50 MB)
# Один процесс: java -jar app.jar
# Одна БД: PostgreSQL

Переход на microservices

Когда монолит перерастает, переходят на microservices архитектуру:

// Было: один большой монолит
Monolithic App (100 MB, 500k строк кода)

// Стало: несколько независимых сервисов
User Service (15 MB, микросервис)
Order Service (20 MB, микросервис)
Payment Service (10 MB, микросервис)
Notification Service (5 MB, микросервис)
Analytics Service (Python, микросервис)
ML Recommendations (Go, микросервис)

# Каждый сервис:
# - Независимая БД
# - Собственная кодовая база
# - Обновляется отдельно
# - Может быть на разном языке
# - Масштабируется независимо

Гибридный подход: Modular Monolith

Это компромисс между монолитом и microservices:

// Один процесс (как монолит)
// Но структурирован как несколько модулей (как microservices)

src/main/java/
├── user-module/
│   ├── UserController.java
│   ├── UserService.java
│   └── UserRepository.java
├── order-module/
│   ├── OrderController.java
│   ├── OrderService.java
│   └── OrderRepository.java
└── payment-module/
    ├── PaymentController.java
    ├── PaymentService.java
    └── PaymentRepository.java

# Преимущества монолита (производительность, простота)
# + Преимущества модульности (изоляция, слабый coupling)
# В будущем просто переделать на microservices

Заключение

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

✅ Быстроту разработки ✅ Простоту отладки ✅ Хорошую производительность ✅ Простоту управления

Однако, когда приложение растёт, особенно при 50+ разработчиков и миллионах пользователей, нужно подумать о переходе на microservices или modular monolith архитектуру.

Главное правило: выбирайте архитектуру исходя из реальных потребностей, а не из моды. Монолит на 2024 год — это абсолютно нормальный выбор для большинства компаний.