[1/2] Introducing Domain-Oriented Microservice Architecture (Рубрика Architecutre)

В 2020 году Adam Gluck написал интересный пост про редизайн микросервисной архитектуры Uber и переход на DOMA. А потом Адам уволился и пошел пилить свой стартап, но к делу это не относится:) Если вернуться к статье, то Адам описал стадии эволюции архитектуры

1. Монолитная архитектура (примерно 2012-2013), где было 2 больших сервиса и набор проблем: риски доступности, опасные деплои, poor separation of concerns, плохой execution изменений в бизнес-логике. Эти проблемы возникли при росте от десятков инженеров к сотням
2. При решении этих проблем ребята пошли в микросервисную архитектуру ради: общесистемной надежности, separation of concerns, ясной ответственности и владения (ownership), скорости разработки (developer velocity). Ребята на начальных этапах получили все запланированное, но при росте команды до тысяч инженеров возник распределенный монолит
3. С 2018 года шла работа над новой концепцией под названием DOMA (Domain-oriented microservice architecture), в которой ребята решили, что микросервисы - это просто i/o-bound библиотеки, а микросервисная архитектура - это большое распределенное приложение, то для его архитектуры можно использовать стандартные подходы

• Domain-driven design - про эту концепцию интереснее всего читать у Влада Хононова в книге "Learning DDD", на которую я написал 4 кратких обзора: общий обзор DDD, DDD и микросервисы, DDD и event-driven architecture, DDD и data mesh
• Clean architecture - лучше всего изучить книгу Книга "Clean Architecture" и ее часть про дизайн модулей - мое краткое саммари этой части здесь
• Service-oriented architecture - это предтеча микросервисной архитектуры:) И на выходе получаться принципы для дизайна крупных распределенных систем в больших организациях.

Основные принципы DOMA такие

1. Вместо ориентации на отдельные микросервисы надо ориентироваться на их коллекции, что организованы вокруг доменов
2. На самом деле домены тоже объединяются в коллекции, которые называются уровнями. Уровни определяют то, какие зависимости могут быть у микросервисов внутри домена. Базовое правило - это то, что микросервисы из верхних уровней могут зависеть только от микросервисы с нижних уровней. Авторы называют это слоенным дизайном. Для меня он напоминает семиуровневую модель OSI (||технологии часто развиваются по кругу||)
3. Домены предоставляют чистые интерфейсы (clean interfaces), которые являются единой входной точкой в коллекцию. Такие входные точки называются gateways
4. Зависимостями между доменами быть не может - ни по коду, ни по моделям данных. Для того, чтобы сделать доступным включение логики из одного домена в другой (например, для кастомной валидации или мета контекста) авторы предоставляют точки расширения внутри доменов

Имплементация выглядит так, что домены позволяют подумать о логической роли коллекции микросервисов и могут быть разных размеров. Коллекции доменов в виде слоев представляют из себя способ управления специфичностью слоя и его бласт радиусом. Всего в Uber были выделены пять слоев

1. Infrastructure layer. Provides functionality that any engineering organization could use. It’s Uber’s answer to the big engineering questions, such as storage or networking.
2. Business layer. Provides functionality that Uber as an organization could use, but that is not specific to a particular product category or line of business (LOB) such as Rides, Eats, or Freight.
3. Product layer. Provides functionality that relates to a particular product category or LOB, but is agnostic to the mobile application, such as the “request a ride” logic which is leveraged by multiple Rides facing applications (Rider, Rider “Lite”, m.uber.com, etc).
4. Presentation. Provide functionality that directly relates to features that exist within a consumer-facing application (mobile/web).
5. Edge Layer. Safely exposes Uber services to the outside world. This layer is also mobile application aware.

Окончание обзора в следующем посте.

#DistributedSystems #Architecture #SystemDesign #Engineering #Software