В курсе девять видеоуроков по 30-45 минут.
В каждом описываются подходы, концепции и термины.
Цель — объяснить, что такое асинхронная архитектура, из какой проблемы она появилась, какие проблемы решает, и поделюсь личным опытом её использования. А также рассказать, что вообще на курсе делать будем.
Какую проблему решаем? Если у вас монолит или сервисы — скорее всего, вы сталкивались с распределённым монолитом. Обычно это система, в которой очень высокая связанность как синхронных, так и асинхронных коммуникаций.
Асинхронная архитектура, основанная на «хотелках» бизнеса, может помочь в изоляции и разделении системы на части. А система инвентаризации, которую спроектируем во время курса, покажет, как добиться этого.
Ключевые концепции и термины: асинхронная архитектура, distributed monolith (синхронный и асинхронный), уменьшение связанности частей системы, distributed event streaming, EDA (event driven architecture), sync/async RPC.
На выходе: поймём, что такое и зачем нужна асинхронная архитектура, получим определённость того, что и зачем будем делать. Т. е. у нас уже есть начальная точка, а после первого урока появится конечная точка.
Цель — показать, что проектирование всегда начинается от бизнеса. Получив хотелки, их можно разложить на две части, получить данные и что-то сделать. Мы будем использовать концепцию, похожую на event storming. К сожалению, ES не хватает, поэтому я поделюсь недостающим звеном в виде модели данных, которая поможет нам определить связанность данных, найти домены системы инвентаризации.
Какую проблему решаем? Обычно системы проектируют во время реализации, и бизнес редко уделяет время проектированию до начала работы, так как результат непонятен. Но благодаря проектированию можно получить хайлевел-картинку, избежать переключения контекста с хайлевел на лоулевел, заранее спланировать работу и оценить затраты (примерные).
Само проектирование обычно состоит из набора юзерстори и примерных задач в джире, которые не понятно, как связаны. В нашем случае я расскажу о шести шагах, которые делаю для любого проекта: сбор требований, описание query/commands, создание модели данных, поиск доменов, разделение сервисов и определение коммуникаций между сервисами. В этом уроке поговорим только о первых трёх шагах.
К тому же обычно вспоминают о данных, которые надо между частями системы гонять в последнюю очередь, проектирование позволяет сразу определить, что, куда и в каком виде надо передать.
Ключевые концепции и термины: event storming, определение доменов, strategy level from DDD, модель данных, функциональные требования.
На выходе: на примере системы инвентаризации покажу, как рассмотреть полученные требования с точки зрения бизнеса. Т. е. определиться, что вообще хочет бизнес (какие данные ему нужны и какие команды он хочет выполнять), с помощью ES like — подхода, а также составим модель данных, поймём, почему UML/ERD может быть избыточен. А благодаря модели данных и ES-описанию сможем закрыть все вопросы по проектированию системы.