Что такое монолитная архитектура?

Монолитная архитектура

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

Структура монолитной архитектуры

┌─────────────────────────────────────┐
│     MONOLITHIC APPLICATION          │
├─────────────────────────────────────┤
│                                     │
│  ┌──────────────┐  ┌──────────────┐ │
│  │  User Module │  │ Order Module │ │
│  └──────────────┘  └──────────────┘ │
│         ↕                  ↕         │
│  ┌──────────────┐  ┌──────────────┐ │
│  │Payment Module│  │Inventory Mod.│ │
│  └──────────────┘  └──────────────┘ │
│         ↕                  ↕         │
│  ┌─────────────────────────────────┐ │
│  │   Shared Database (PostgreSQL)  │ │
│  └─────────────────────────────────┘ │
│                                     │
└─────────────────────────────────────┘
         ↓
   Развёртывание как
    один процесс

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

1. Единственная кодовая база

Все функции приложения находятся в одном репозитории:

project/
├── src/
│   ├── users/
│   │   ├── models.py
│   │   ├── services.py
│   │   └── handlers.py
│   ├── orders/
│   │   ├── models.py
│   │   ├── services.py
│   │   └── handlers.py
│   ├── payments/
│   │   ├── models.py
│   │   ├── services.py
│   │   └── handlers.py
│   └── shared/
│       ├── database.py
│       ├── auth.py
│       └── utils.py
├── migrations/
├── tests/
└── requirements.txt

2. Единый процесс

При запуске приложение стартует как один процесс (или несколько копий одного процесса):

# Стартуем одно Java приложение
java -jar application.jar

# Или несколько копий для балансировки нагрузки
java -jar application.jar &
java -jar application.jar &
java -jar application.jar &

3. Синхронная коммуникация

Модули взаимодействуют друг с другом через прямые вызовы методов (в памяти одного процесса):

// OrderService вызывает PaymentService напрямую
public class OrderService {
    @Autowired
    private PaymentService paymentService;
    
    public void createOrder(OrderRequest request) {
        // Синхронный вызов
        PaymentResult result = paymentService.processPayment(request.amount);
        // Ждём результата
    }
}

4. Единая база данных

Все модули используют одну базу данных, часто с прямым доступом к таблицам друг друга:

-- Пользователи в таблице users
CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    email VARCHAR(255)
);

-- Заказы в таблице orders
CREATE TABLE orders (
    id SERIAL PRIMARY KEY,
    user_id INTEGER REFERENCES users(id),
    total_amount DECIMAL
);

-- Платежи в таблице payments
CREATE TABLE payments (
    id SERIAL PRIMARY KEY,
    order_id INTEGER REFERENCES orders(id),
    status VARCHAR(50)
);

5. Единое развёртывание

Всё приложение развёртывается как одно целое изменениями в любом модуле требует переразвёртывания всего приложения:

# Изменили функцию в UserService
# НУЖНО переразвернуть ВСЁ приложение
docker build -t app:v2.0 .
docker push app:v2.0
kubectl set image deployment/app app=app:v2.0

Преимущества монолитной архитектуры

1. Простота разработки на начальном этапе

• Быстрое стартирование проектов
• Меньше infrastructure для управления
• Легче отладить — всё в одном процессе
• IDE отлично поддерживает переходы между модулями

Пример: Стартап разрабатывает MVP приложение. Монолит позволяет развернуть функционал за 2-3 месяца.

2. Легкая коммуникация между модулями

• Прямые вызовы методов в памяти
• Без сетевой задержки между компонентами
• ACID транзакции легко охватывают несколько модулей

@Transactional
public void transferMoney(int fromUser, int toUser, BigDecimal amount) {
    // Обновляем баланс пользователя 1
    userService.updateBalance(fromUser, amount.negate());
    // Обновляем баланс пользователя 2
    userService.updateBalance(toUser, amount);
    // Если что-то пошло не так — откатываем ВСЁ
}

3. Проще управлять транзакциями

• ACID гарантии легко реализовать
• Откат при ошибке автоматический
• Нет необходимости в distributed transactions

4. Проще с производительностью на малых масштабах

• Нет сетевой задержки между компонентами
• Общий кеш для всех модулей
• Легче оптимизировать при нормальных объёмах

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

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

Проблема: При росте приложения монолит становится всё больше и сложнее.

V1 (10K LOC)  → Легко управлять
V2 (50K LOC)  → Начинают появляться зависимости
V3 (200K LOC) → Очень сложная для понимания
V4 (500K LOC) → Практически невозможно модифицировать

Решение: Только вертикальное масштабирование (более мощные серверы), но есть физический предел.

2. Медленный цикл разработки

• Изменение в любом модуле требует переразвёртывания всего приложения
• Долгие time-to-market для новых функций
• Высокие риски при развёртывании (может упасть вся система)

Сценарий: Нужно исправить ошибку в модуле UserService

Монолит:
1. Разработчик готовит fix → 2 часа
2. Тестирование ВСЕХ модулей → 4 часа
3. Развёртывание ВСЕГО приложения → 1 час
4. Проверка работоспособности всей системы → 2 часа
Итого: 9 часов

Микросервисы:
1. Разработчик готовит fix → 2 часа
2. Тестирование UserService → 30 минут
3. Развёртывание только UserService → 5 минут
4. Проверка UserService → 10 минут
Итого: 2 часа 45 минут

3. Зависимость модулей (Tight Coupling)

• Сложно изолировать модули для тестирования
• Изменение в одном модуле может сломать другой
• Сложно повторно использовать модули в других приложениях

// OrderService напрямую зависит от PaymentService
public class OrderService {
    private PaymentService paymentService = new PaymentService();
    
    // Сложно тестировать, нельзя подменить на mock
}

4. Технологический lock-in

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

Добавить компонент на Node.js к Java приложению? Очень сложно.
Употреблять Python для ML модели? Нужно интегрировать в Java

5. Масштабирование ресурсов неэффективно

• Нужно масштабировать всё приложение, даже если bottleneck в одном модуле
• Пример: PaymentService требует 10 экземпляров, но приходится масштабировать всё

6. Сложность управления (DevOps)

• Большие артефакты (JAR, Docker image)
• Долгое развёртывание
• Высокие требования к мониторингу и логированию (всё в одном месте)

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

Структура: E-commerce платформа

E-Commerce Monolith (Java + Spring Boot + PostgreSQL)
├── user-management/
│   ├── Registration
│   ├── Authentication
│   ├── Profile Management
│   └── Address Book
├── product-catalog/
│   ├── Product Search
│   ├── Product Details
│   └── Recommendations
├── shopping-cart/
│   ├── Add to Cart
│   ├── Update Cart
│   └── Cart Checkout
├── order-management/
│   ├── Create Order
│   ├── Order Tracking
│   └── Order History
├── payment-processing/
│   ├── Payment Gateway Integration
│   ├── Refunds
│   └── Transaction History
├── inventory-management/
│   ├── Stock Updates
│   ├── Warehouse Management
│   └── Low Stock Alerts
└── shared/
    ├── Authentication
    ├── Database Access
    ├── Logging
    └── Error Handling

Всё это один Spring Boot сервис, который развёртывается как одно приложение.

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

✅ Хорошо подходит:

• MVP и стартапы — нужна быстрая разработка
• Малые и средние приложения (< 100K LOC)
• Команды < 20 разработчиков
• Простые domain-модели с минимальной интеграцией
• Критичны ACID транзакции (e-commerce, banking)

❌ Плохо подходит:

• Большие системы (> 500K LOC)
• Высоконагруженные системы с неравномерными требованиями
• Команды > 50 разработчиков
• Разные требования к scalability для разных модулей

Вывод

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