Доменно-ориентированная микросервисная архитектура ценна тем, что ставит бизнес-границы выше сетевых схем и диаграмм вызовов.
Для реального проектирования глава помогает увидеть, как домены, слои, контракты шлюза домена, точки расширения и ответственность команд начинают работать вместе только тогда, когда организационная структура не спорит с архитектурой.
Для интервью и инженерных разборов она полезна тем, что помогает обсуждать DOMA через организационную связанность, узкие места у команд общей платформы и цену координации на большом масштабе.
Практическая польза главы
Практика проектирования
Связывайте доменные границы, слои зависимостей и зоны ответственности команд.
Качество решений
Согласовывайте контракты шлюза домена, точки расширения и платформенные API.
Аргументация на интервью
Показывайте, как архитектура и устройство организации вместе влияют на скорость поставки изменений.
Анализ отказов
Контролируйте риск организационной связанности и узкие места у команд общей платформы.
Источник
Uber Engineering, 2020
Оригинальная статья Adam Gluck о редизайне архитектуры Uber и переходе к DOMA.
DOMA - это , которую Uber использовал для управления очень большой микросервисной экосистемой. Ключевая идея: проектировать не россыпь изолированных сервисов, а доменные коллекции сервисов со строгими контрактами, слоями зависимостей и точками расширения.
По духу этот подход объединяет идеи из DDD и архитектурной модульности, но применяет их к масштабу тысяч инженеров и тысяч сервисов.
Эволюция архитектуры Uber
Монолитная архитектура
У Uber было два крупных сервиса. По мере роста команды от десятков к сотням инженеров начали расти риски доступности, сложность деплоев и стоимость изменений.
- Риски доступности: падение крупного компонента влияло на большую часть продукта.
- Опасные релизы: одно изменение могло задеть слишком большую часть продукта.
- Слабое разделение ответственности между .
- Медленное проведение изменений в бизнес-логике.
Переход к микросервисам
Ставка на надёжность, ответственность команд и скорость разработки сначала сработала. Но при росте до тысяч инженеров система стала напоминать с избыточными связями.
- Чрезмерное число межсервисных зависимостей.
- Сложная трассировка причин инцидентов через много команд.
- Неочевидные границы ответственности и моделей данных.
- Рост когнитивной нагрузки для разработчиков.
DOMA (Domain-Oriented Microservice Architecture)
Uber переосмыслил микросервисную систему как одно большое распределённое приложение и применил к ней архитектурные принципы , слоёв, контрактов и расширяемости.
- Фокус смещается с отдельных сервисов на домены как единицы дизайна.
- Зависимости становятся управляемыми через .
- Внешние интеграции идут через .
- Кросс-доменные интеграции проходят через , а не через прямую связность.
Принципы DOMA
Дизайн вокруг доменов, а не отдельных сервисов
Ключевая единица проектирования - , которая закрывает доменную задачу целиком. Это упрощает и планирование изменений.
Домены группируются в слои
Сервисы верхнего уровня могут зависеть только от нижнего. Такое ограничивает циклы и снижает при изменениях.
У домена есть явный входной контракт
становится единой входной точкой, стабилизирует внешний и позволяет безопасно менять внутреннюю реализацию.
Прямых кросс-доменных зависимостей нет
Ни общего кода, ни общей модели данных между доменами. Для особых сценариев интеграции используются контролируемые .
Слои DOMA в Uber
| Слой | Назначение | Примеры |
|---|---|---|
| Инфраструктурный слой | Базовые , нужные любой инженерной организации: хранение, сеть, наблюдаемость и инфраструктурная идентификация. | API хранения, сетевые примитивы, инфраструктурная идентификация, инструменты среды выполнения |
| Бизнес-слой | Общие бизнес-возможности Uber, не привязанные к одному вроде Rides, Eats или Freight. | Платёжные политики, сигналы антифрода, пользовательские профили |
| Продуктовый слой | Логика конкретной , но без привязки к одному клиентскому приложению. | Жизненный цикл заказа поездки, правила диспетчеризации, логика доступности водителей |
| Слой представления | Функциональность, привязанная к пользовательским интерфейсам: мобильному приложению или вебу. | Сценарии экранов заказа, координация действий из интерфейса, правила UX для конкретного приложения |
| Пограничный слой | Безопасная экспозиция API наружу и адаптация под особенности клиентских приложений. | Пограничные шлюзы, политики авторизации, композиция API, адаптация запросов |
Базовое правило: сервисы верхнего слоя зависят только от сервисов нижележащих слоев.
Контракты
Паттерны межсервисной коммуникации
Шлюз домена и точки расширения работают только при явных, стабильных контрактах между командами.
Шлюз домена и точки расширения
Расширение логики через плагины
Сервисы внутри домена предоставляют . Команды подключают дополнительную доменную проверку без ответвления базовой логики.
Расширение модели данных через необязательные поля
К базовой модели добавляются , чтобы не создавать прямую связь между доменами на уровне .
Локальные точки расширения команд
Команды могут вводить дополнительные точки расширения внутри своего домена, сохраняя контроль контракта и жизненного цикла.
Практический эффект шлюза домена: команда может переносить внутренние сервисы, не ломая потребителей, пока внешний контракт остаётся стабильным.
Что получилось на выходе
- Снижение сложности за счёт перехода от 2200 сервисов к примерно 70 доменам как управляемым единицам.
- Более предсказуемые зависимости благодаря слоистой архитектуре и строгому .
- Более простые миграции и независимые релизы доменов через стабильные контракты шлюза домена.
- Снижение когнитивной нагрузки разработчиков и ускорение локализации инцидентов.
Когда выбирать монолит, микросервисы и DOMA
| Размер организации | Базовый выбор | Почему |
|---|---|---|
| Стартап | Монолит или | Минимальная операционная сложность, быстрая проверка рынка и низкая цена изменений. |
| Средняя компания | Классические микросервисы | Нужна независимая поставка несколькими командами и контроль технологических рисков по подсистемам. |
| Крупная организация | DOMA-подход | Нужна управляемость тысяч инженеров, доменные границы, масштабируемое и снижение системной связанности. |
Типичные ошибки при внедрении DOMA
Называть доменом любой случайный набор сервисов без явной бизнес-границы и модели ответственности.
Делать шлюз домена тонкой прослойкой без контракта, и соглашения об уровне сервиса между доменами.
Оставлять или между доменами и называть это DOMA.
Строить слои формально, но нарушать правило зависимостей: верхние слои обращаются к сервисам того же или верхнего слоя.
Источники
Связанные главы
- Зачем нужны микросервисы и интеграция - Контекст для выбора сервисных границ и интеграционных подходов до внедрения доменно-ориентированной модели.
- Стратегии декомпозиции - Практика выделения ограниченных контекстов и поэтапного снижения связности без потери управляемости.
- Learning Domain-Driven Design (short summary) - DDD-основа для формирования доменов, ответственности команд и контрактов, на которых строится DOMA.
- Паттерны межсервисной коммуникации - Подходы к синхронному и асинхронному взаимодействию, которые стабилизируют контракты шлюза домена и кросс-доменные интеграции.
- Обнаружение сервисов (service discovery) - Инфраструктурный слой обнаружения сервисов для масштабируемого взаимодействия доменных компонентов.
- Monolith to Microservices (short summary) - Пошаговый план перехода от монолита к сервисной архитектуре с контролем рисков и связности.
- Uber/Lyft - Прикладной контекст компании, где доменная декомпозиция и архитектурное управление критичны для масштаба.