Декомпозировать нельзя остановиться: как мы Биллинг Яндекс 360 делили

Архитектура и масштабируемость

Платёжные системы, обработка платежей
Java
Архитектурные паттерны
Отказоустойчивость
Распределенные системы
Рефакторинг
Архитектуры / другое
Поддержка и развитие legacy систем
Микросервисы

Программный комитет ещё не принял решения по этому докладу

Целевая аудитория

Бэкенд-разработчики, архитекторы, техлиды и руководители разработки, которые сталкиваются с распилом legacy-монолита, проектированием биллинговых/платёжных систем и выбором между микросервисами и модульным монолитом.

Тезисы

Биллинг Яндекс 360 — это сервис над которым работают 6 продуктовых команд. Бэклоги всех команд полны сложных и интересных фичей. При этом требуется максимальная стабильность сервиса для работы с деньгами пользователей. Архитектура монолита стала снижать наши темпы роста, а инциденты стали влиять на все продукты сразу.

В докладе расскажу, как мы подходили к задаче декомпозиции монолита с помощью DDD и Event Storming. Почему иногда стоит остановиться на прагматичном подходе распиливания на модульные монолиты и не стремиться распилить на множество микросервисов.

Илья Иванов

Яндекс 360

Java-разработчик в Яндекс 360. Занимается разработкой биллинга и платформы подписочных механик.

Видео

Другие доклады секции

Архитектура и масштабируемость