Software Architect · Модуль 11
Монолит не означает хаос, а микросервисы не означают архитектуру. Важны границы, ownership и операционная зрелость.
Modular monolith · service boundaries · operational complexity
Микросервисы покупают независимость ценой распределённой сложности. Если независимость не нужна, цена может быть лишней.
Сервис — это организационная единица
Отдельный офис полезен, когда у команды есть своя работа, ритм и ответственность. Если все всё равно сидят на одном созвоне, стены не помогают.
Микросервис оправдан, когда контекст имеет отдельный жизненный цикл, команду-владельца, нагрузочный профиль, требования безопасности или релизный ритм. Просто вынести код в отдельный deployable unit недостаточно.
Modular monolith часто лучше на ранней стадии: одна кодовая база и deployment, но строгие внутренние модули, публичные interfaces, запрет циклических зависимостей и ясный ownership.
Распределение добавляет операционную цену
Одна кухня может быть тесной. Десять кухонь требуют логистики, связи, расписания поставок и правил передачи блюд.
Микросервисы требуют service discovery, observability, network security, backward-compatible contracts, distributed tracing, deployment orchestration, incident response, data ownership и SRE-практики. Это не минус, если есть причина. Это цена.
Архитектор должен честно спросить: какая боль исчезнет после split и какая новая боль появится?
Хороший split уменьшает координацию. Плохой split создаёт больше согласований, чем было до него.
Пример: выделить billing
Касса, бухгалтерия и склад связаны, но у бухгалтерии свои правила, аудит и ответственность.
Billing имеет отдельные compliance-требования, audit trail, интеграции с payment providers и команду-владельца. Его можно выделить в сервис с собственными данными и контрактами: invoices, subscriptions, payment events.
Такой split понятен: он защищает домен с высокой ценой ошибки и отдельным темпом изменений.
Антипример: микросервис на каждую таблицу
Если каждая полка склада стала отдельным магазином, покупателю придётся пройти десять касс ради одного заказа.
Команда делает users-service, profiles-service, addresses-service, roles-service, но любой use case требует вызовов всех четырёх. Данные всё равно связаны, релизы всё равно совместные, а latency и debugging стали хуже.
Это distributed monolith: сервисы есть, независимости нет.
- Какая команда будет владеть сервисом? - Может ли сервис релизиться независимо? - Чьи данные он владеет? - Какие новые operational responsibilities появятся после split?