Асинхронная архитектура. Тариф «Я сам» (Фёдор Борщёв, Антон Давыдов)

​

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

Проблема обычно в неудачных способах взаимодействия систем между собой. Если ходить друг в друга по HTTP API — получается распределённый монолит. Если ходить асинхронно — приходится решать кучу проблем с целостностью данных.

Мы расскажем, как избежать этих проблем.

CTO и программист
Сделаем полноценный проект — систему для крупной компании на event-driven архитектуре по принципам DDD.
Будем не только рисовать кучу квадратиков в LucidChart, но и писать код. Авторы — на Ruby, вы — на чём угодно. Задача — создать систему инвентаризации оборудования для крупной компании.

Основные требования: состояние товаров, статус ремонта, authn и authz, аудитлог, интеграция с монолитом. Используем Kafka, Event Streaming, Schema Registry. Упомянем о CQRS и SAGA.
Подойдёт всем, кто интересуется архитектурой ПО

Достаточно читать на любом языке программирования, знать хотя бы один популярный MVC-фреймворк и понимать, для чего нужны RabbitMQ/Kafka.

Спойлер: Программа:

Интро
Урок 1. Разбираем, в чем разница между распределённым монолитом и асинхронной системой.

Проектирование
Урок 2. Event Storming — превращаем требования в модель данных и процессы.
Урок 3. Переходим от процессов и модели данных в сервисы и коммуникации.

Имплементация
Урок 4. Аутентификация и авторизация: выбираем между jwt, токенами, SAML и oauth.
Урок 5. Пишем первый сервис: события, data streming. Выбираем брокер сообщений.

Развитие
Урок 6. Учимся тестировать и поддерживать асинхронные системы : эволюция событий, schema registry.
Урок 7. Делаем нотификации и аналитику на основе стриминга данных.
Урок 8. Разбираемся, на что обращать внимание, куда смотреть и что делать в будущем.

Скрытый текст. Доступен только зарегистрированным пользователям.Нажмите, чтобы раскрыть...