Мнение Программного комитета о докладе
Мы хотим перенести наши синхронные взаимодействия в асинхронные. Просто звучит — на деле же непросто. Антон на своем опыте и примерах расскажет, как использовать событийную архитектуру правильно.
Как начать использовать событийную модель в сервисах и не свалиться в распределенный монолит
Доклад принят в программу конференции
Целевая аудитория
Архитекторы, которые решили перевести систему на асинхронные коммуникации; разработчики с негативным опытом (или вообще без опыта) написания событийных сервисов; тимлиды, желающие разобраться со сложностями подобных затей и те, кто хочет развиваться как инженер.
Тезисы
В своей практике часто вижу, как реализация нового сервиса с асинхронными коммуникациями или перенос синхронных коммуникаций на асинхронные сваливается в долгострой, который приводит к распределенному монолиту или проблемам, связанным со сложностью поддержки асинхронных систем.
Мне кажется, что причина подобных результатов — в самом начале думать о деталях реализации и о том, как решить задачу, вместо того, что бы разобраться, что нужно сделать и какие ограничения должны быть у новой системы. Это приводит к повышению киплинга системы, так как элементы и их коммуникации друг с другом анализируются по ходу реализации или партицируются по технической реализации, а не по бизнесу.
В докладе хочу рассказать о способе перехода на события в системе. Основную идею можно описать в пяти шагах:
* разбор требований и поиск характеристик необходимых системе;
* моделирование поведения системы от бизнеса;
* моделирование основных данных, необходимых для работы системы;
* анализ необходимых доменов, сервисов и коммуникаций;
* дизайн системы, основанной на шагах выше, и последующая имплементация решения.
На примерах трех систем из своего опыта (биллинг/аккаунтинг, система финансового анализа и полного переписывания школы для подготовки детей к ЕГЭ/ОГЭ) покажу каждый из шагов, а также расскажу, какие подводные камни встретились по ходу работы. Еще поговорим о том, почему необходимо использовать разные виды событий, как избежать проблем со схемой событий во время добавления новой логики, и что делать в случае возможных потерь или проблем с ордерингом.
Работает Solution Architect последние 3 года, до этого семь лет писал код. Много писал в опенсорс, является одним из кор-разработчиков dry-rb.org и hanamirb.org, а его коммиты можно найти в руби, рельсе и других проектах.
На данный момент полностью переключился на архитектуру и распределенные системы, поэтому с радостью поговорит о событиях, системах и работе с architecture descriptions.
Помогает разным компаниям с архитектурой, сбором требований, распилом монолита на сервисы или с проблемами, связанными с текущим дизайном асинхронных коммуникаций и распределенных монолитов.
.
Видео
Другие доклады секции
Про архитектуру
