Uber публично задокументировал свой подход к организации микросервисов — Domain-Oriented Microservice Architecture (DOMA). Он решает проблему колоссального возрастания сложности системы у организаций с несколькими тысячями микросервисов. Для организаций меньшего масштаба весь подход будет избыточен, а вот идею «слоёного дизайна» стоит почерпнуть. Принцип заключается в разделении системы на иерархию слоёв. В самом низу лежат инфраструктурные сервисы, наверху — реализация продуктовых фич и представления данных для фронтенда. Прямые зависимости между сервисами допустимы только внутри слоя, а в соседний слой можно сходить через единую точку входа. Причём соседний — это нижний. Слой может зависеть только от слоя, который находится под ним. Например, продукт с оплатой услуг раскладывается на три слоя (сетевую инфраструктуру и гейтвеи фронтенда для простоты отброшу): Биллинговая система, оперирующая платёжками, реквизитами юр. лиц, данными банковских карт, чеками и тому подобным, на нижнем слое иерархии. Она может быть использована в принципиально разных продуктах, главное, чтобы они забирали деньги у пользователей; Сервисы ценообразования и механики применения услуг в конкретных продуктовых доменах. На этом слое может быть несколько сервисов, если у направлений бизнеса отличается логика тарификации; * Продуктовые сервисы, реализующие юзер-стори. Отчётливо видно движение от универсальной функциональности к специфичной и от высокой критичности к низкой. Развалится биллинг — пострадают все, а если продуктовый сервис — только его фича. Когда пользователь активирует платную услугу, продуктовый слой обращается только к соседу ниже запросами вида «активируй услугу X пользователю Y». Он не работает с биллингом и тем более не реализует бизнес-логику в терминах биллинговых систем. Нижний слой тоже не обращается к продуктовому и не знает его моделей. Важно не использование «слоёв» в каноничном уберовском понимании, а наличие иерархии в организации системы. Без неё сложность растёт неконтролируемо: домены переплетаются, экспертиза размазывается между командами, граф зависимостей сервисов превращается в ёжика. Выделить правильную иерархию без лишних абстракций — сложная архитектурная задача, но даже несовершенная иерархия лучше её отсутствия.