Конференция завершена. Ждем вас на TechLead Conf в следующий раз!

Как начать использовать событийную модель в сервисах и не свалиться в распределенный монолит

Про архитектуру

Миграции данных
Бэкенд / другое
Микросервисы, SOA
Асинхронное программирование, реактивное программирование
Архитектурные паттерны
Распределенные системы
Методы и техника разработки ПО
Архитектура данных, потоки данных, версионирование
Проектирование информационных систем
Микросервисы
Теория
Расширение кругозора

Доклад принят в программу конференции

Мнение Программного комитета о докладе

Мы хотим перенести наши синхронные взаимодействия в асинхронные. Просто звучит — на деле же непросто. Антон на своем опыте и примерах расскажет, как использовать событийную архитектуру правильно.

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

Архитекторы, которые решили перевести систему на асинхронные коммуникации; разработчики с негативным опытом (или вообще без опыта) написания событийных сервисов; тимлиды, желающие разобраться со сложностями подобных затей и те, кто хочет развиваться как инженер.

Тезисы

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

Мне кажется, что причина подобных результатов — в самом начале думать о деталях реализации и о том, как решить задачу, вместо того, что бы разобраться, что нужно сделать и какие ограничения должны быть у новой системы. Это приводит к повышению киплинга системы, так как элементы и их коммуникации друг с другом анализируются по ходу реализации или партицируются по технической реализации, а не по бизнесу.

В докладе хочу рассказать о способе перехода на события в системе. Основную идею можно описать в пяти шагах:
* разбор требований и поиск характеристик необходимых системе;
* моделирование поведения системы от бизнеса;
* моделирование основных данных, необходимых для работы системы;
* анализ необходимых доменов, сервисов и коммуникаций;
* дизайн системы, основанной на шагах выше, и последующая имплементация решения.

На примерах трех систем из своего опыта (биллинг/аккаунтинг, система финансового анализа и полного переписывания школы для подготовки детей к ЕГЭ/ОГЭ) покажу каждый из шагов, а также расскажу, какие подводные камни встретились по ходу работы. Еще поговорим о том, почему необходимо использовать разные виды событий, как избежать проблем со схемой событий во время добавления новой логики, и что делать в случае возможных потерь или проблем с ордерингом.

Работает Solution Architect последние 3 года, до этого семь лет писал код. Много писал в опенсорс, является одним из кор-разработчиков dry-rb.org и hanamirb.org, а его коммиты можно найти в руби, рельсе и других проектах.

На данный момент полностью переключился на архитектуру и распределенные системы, поэтому с радостью поговорит о событиях, системах и работе с architecture descriptions.

Помогает разным компаниям с архитектурой, сбором требований, распилом монолита на сервисы или с проблемами, связанными с текущим дизайном асинхронных коммуникаций и распределенных монолитов.

.

Видео

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

Про архитектуру