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

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

Поэтому, в докладе хочу рассказать о способе перехода на события в системе. Основную идею можно описать в пяти шагах:

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

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