Ответ
Проект использовал гибридную архитектуру: ядро было построено как микросервисы, но некоторые унаследованные модули сохраняли монолитные черты.
Почему был выбран гибридный подход?
- Цель: Быстрый вывод MVP на рынок.
- Причина: Рефакторинг всего legacy-кода сразу был бы слишком затратным.
Сравнение частей системы:
| Компонент | Архитектура | Технологии | Причина |
|---|---|---|---|
| Сервис заказов | Монолитный модуль | Spring Boot, JPA, встроенная БД | Унаследованный код, тесная связность бизнес-логики. |
| Платежный сервис | Отдельный микросервис | Spring Boot, REST, отдельная БД | Необходимость независимого масштабирования и обновления. |
Пример монолитного модуля (упрощенно):
@Service
public class LegacyOrderService {
@Transactional
public Order processOrder(Order order) {
// Плотная связность: валидация, бизнес-логика, вызовы БД в одном месте
validate(order);
calculatePrice(order);
orderRepository.save(order);
inventoryService.updateStock(order); // Внутренний вызов
return order;
}
}
Плюсы и минусы подхода:
- Плюс: Высокая скорость разработки на начальном этапе.
- Минус: Сложности с изолированным масштабированием и развертыванием монолитных частей.
Эволюция: Архитектура предполагала постепенное выделение bounded context'ов из монолита в отдельные микросервисы.