Асинхронная архитектура [Пакет - Я сам] [Школа сильных программистов] [Фёдор Борщёв, Антон Давыдов]

Вы приняты | Анализ систем В новом потоке все ролики будут новыми. Заодно мы пересмотрели контент — переделали содержимое уроков, один убрали, два добавили. ​ О чем курс Компании, которые уходят от монолитной архитектуры к сервисной и микросервисной, часто терпят поражение — получают такой же монолит, только разбитый по нескольким репозиториям. Мы расскажем, как избежать этих проблем — правильно разнести функциональность по сервисам и выбрать подходящий формат асинхронной коммуникации. Вы познакомитесь с Kafka, Event Streaming и понятием Schema Registry. Кроме того, мы упомянем о CQRS и SAGA. Сделаем полноценный проект — систему для крупной компании на event-driven-архитектуре по принципам DDD. Мы не только нарисуем кучу квадратиков в LucidChart, но ещё и напишем код — спроектируем и запилим систему инвентаризации оборудования для крупной компании. Подойдёт всем, кто интересуется архитектурой ПО Достаточно читать на любом языке программирования, знать хотя бы один популярный MVC-фреймворк и понимать, для чего нужны RabbitMQ/Kafka.

​ Компании, которые уходят от монолитной архитектуры к сервисной и микросервисной, часто терпят поражение — получают такой же монолит, только разбитый по нескольким репозиториям. Проблема обычно в неудачных способах взаимодействия систем между собой. Если ходить друг в друга по 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. Разбираемся, на что обращать внимание, куда смотреть и что делать в будущем.

​ Четырёхнедельный онлайн-курс о том, как строить распределённые сервисы. Мы простым языком расскажем о DDD и об архитектуре больших систем. По итогам курса вы спроектируете распределённую систему, которую добавите в портфолио. В новом потоке все ролики будут новыми. Заодно мы пересмотрели контент — переделали содержимое уроков, один убрали, два добавили. О чем курс Компании, которые уходят от монолитной архитектуры к сервисной и микросервисной, часто терпят поражение — получают такой же монолит, только разбитый по нескольким репозиториям. Мы расскажем, как избежать этих проблем — правильно разнести функциональность по сервисам и выбрать подходящий формат асинхронной коммуникации. Вы познакомитесь с Kafka, Event Streaming и понятием Schema Registry. Кроме того, мы упомянем о CQRS и SAGA. Сделаем полноценный проект — систему для крупной компании на event-driven-архитектуре по принципам DDD. Мы не только нарисуем кучу квадратиков в LucidChart, но ещё и напишем код — спроектируем и запилим систему инвентаризации оборудования для крупной компании. Подойдёт всем, кто интересуется архитектурой ПО Достаточно читать на любом языке программирования, знать хотя бы один популярный MVC-фреймворк и понимать, для чего нужны RabbitMQ/Kafka. Теория — 9 видеоуроков Урок 1 Разбираем, в чём разница между распределённым монолитом и асинхронной системой. Урок 2 Переводим язык бизнеса в процессы и модель данных Урок 3 Переводим процессы и модель данных в сервисы и коммуникации Урок 4 Первый сервис — authn в распределённых системах, CUD и Business events на практике Урок 5 Основной сервис инвентаризации, выбор message broker Урок 6 Добавляем незапланированный сервис: эволюция событий в системе Урок 7 После запуска: тестирование, ретраи и обработка ошибочных событий Урок 8 Опыт Антона: 4 асинхронные системы из реальной жизни Урок 9 Итоги и что делать дальше — Конспект самого главного — Список дополнительных материалов Практика — Домашка из 6 частей, без обратной связи Скрытый текст. Открывается зарегистрированным пользователям. ​ Фёдор Борщёв и Антон Давыдов. Больше 20 лет опыта на двоих

​ Компании, которые уходят от монолитной архитектуры к сервисной и микросервисной, часто терпят поражение — получают такой же монолит, только разбитый по нескольким репозиториям. Проблема обычно в неудачных способах взаимодействия систем между собой. Если ходить друг в друга по 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. Разбираемся, на что обращать внимание, куда смотреть и что делать в будущем.

​ Четырёхнедельный онлайн-курс о том, как строить распределённые сервисы. Мы простым языком расскажем о DDD и об архитектуре больших систем. По итогам курса вы спроектируете распределённую систему, которую добавите в портфолио. В новом потоке все ролики будут новыми. Заодно мы пересмотрели контент — переделали содержимое уроков, один убрали, два добавили. О чем курс Компании, которые уходят от монолитной архитектуры к сервисной и микросервисной, часто терпят поражение — получают такой же монолит, только разбитый по нескольким репозиториям. Мы расскажем, как избежать этих проблем — правильно разнести функциональность по сервисам и выбрать подходящий формат асинхронной коммуникации. Вы познакомитесь с Kafka, Event Streaming и понятием Schema Registry. Кроме того, мы упомянем о CQRS и SAGA. Сделаем полноценный проект — систему для крупной компании на event-driven-архитектуре по принципам DDD. Мы не только нарисуем кучу квадратиков в LucidChart, но ещё и напишем код — спроектируем и запилим систему инвентаризации оборудования для крупной компании. Подойдёт всем, кто интересуется архитектурой ПО Достаточно читать на любом языке программирования, знать хотя бы один популярный MVC-фреймворк и понимать, для чего нужны RabbitMQ/Kafka. Теория — 9 видеоуроков Урок 1 Разбираем, в чём разница между распределённым монолитом и асинхронной системой. Урок 2 Переводим язык бизнеса в процессы и модель данных Урок 3 Переводим процессы и модель данных в сервисы и коммуникации Урок 4 Первый сервис — authn в распределённых системах, CUD и Business events на практике Урок 5 Основной сервис инвентаризации, выбор message broker Урок 6 Добавляем незапланированный сервис: эволюция событий в системе Урок 7 После запуска: тестирование, ретраи и обработка ошибочных событий Урок 8 Опыт Антона: 4 асинхронные системы из реальной жизни Урок 9 Итоги и что делать дальше — Конспект самого главного — Список дополнительных материалов Практика — Домашка из 6 частей, без обратной связи Скрытый текст. Открывается зарегистрированным пользователям. ​ Фёдор Борщёв и Антон Давыдов. Больше 20 лет опыта на двоих

​ Четырёхнедельный онлайн-курс о том, как строить распределённые сервисы. Мы простым языком расскажем о DDD и об архитектуре больших систем. По итогам курса вы спроектируете распределённую систему, которую добавите в портфолио. О чем курс: Компании, которые уходят от монолитной архитектуры к сервисной и микросервисной, часто терпят поражение — получают такой же монолит, только разбитый по нескольким репозиториям. Мы расскажем, как избежать этих проблем — правильно разнести функциональность по сервисам и выбрать подходящий формат асинхронной коммуникации. Вы познакомитесь с Kafka, Event Streaming и понятием Schema Registry. Кроме того, мы упомянем о CQRS и SAGA. На выходе получим полностью спроектированную систему, которая отвечает на все вопросы имплементации: разберёмся, какие данные нужны бизнесу, какие команды он хочет выполнять с ES like — подхода, а также составим модель данных, поймём, почему UML/ERD может быть избыточен. Урок 2 Переводим язык бизнеса в процессы и модель данных Урок 3 Переводим процессы и модель данных в сервисы и коммуникации Имплементация Выберем и сделаем механизм аутентификации. Отправим первое асинхронное сообщение, разберёмся в разнице между Distributed message Queue и Distributed log. А так как мы будем использовать kafka — разберёмся, как она работает на базовом уровне. На выходе получим первые два сервиса из проекта системы: SSO и первый сервис для бизнеса. А также свяжем их асинхронной коммуникацией для корректной работы всей системы. Урок 4 Первый сервис — authn в распределённых системах, CUD и Business events на практике Урок 5 Основной сервис инвентаризации, выбор message broker Дорабатываем систему Спроектируем логику для задачи, к которой система не приспособлена, — разберёмся с эволюцией событий и поймём, в каких случаях надо соблюдать прямую, а в каких — обратную совместимость. Сделаем, чтобы с нашей системой можно было спокойно спать ночью: разберёмся в тестировании, чтобы новые фичи ничего не ломали, и придумаем, как обеспечить устойчивость системы и обрабатывать невалидные или failure-события. На выходе разработаем план, что делать, когда изменение данных в событии потенциально может развалить всю систему. Также определим, как лучше тестировать асинхронную систему в каждом из случаев и что делать с событиями, которые сломались на уровне бизнес-логики или которые надо заретраить. Урок 7 После запуска: тестирование, ретраи и обработка ошибочных событий Урок 6 Добавляем незапланированный сервис: эволюция событий в системе Личный опыт и выводы Подведём итоги курса: поговорим о проблемах, которые Антон наблюдал в системах, мигрирующих на асинхронную коммуникацию. Это нейминг, проектирование, техническая реализация. Затронем data management patterns, чтобы показать, что это отдельные концепции, которые могут использоваться в асинхронной архитектуре, но не обязательно должны быть в ней. Обсудим, как практиковаться после курса и где искать идеи и места для новых проектов. На выходе: составим список подводных камней и советов, которые помогут избежать проблем. Получим цельную картину и шаги/темы для дальнейшего изучения. Урок 9 Итоги и что делать дальше Урок 8 Опыт Антона: 4 асинхронные системы из реальной жизни Тарифы: Теория — 9 видеоуроков — Факультатив по биллингу и модели данных в записи — Конспект самого главного — Список дополнительных материалов Практика — Домашка из 6 частей, без обратной связи Бонусы — Доступ к материалам после окончания курса — 4 месяца ​

Асинхронная архитектура [Пакет - Я сам] [Школа сильных программистов] [Фёдор Борщёв, Антон Давыдов]​ Четырёхнедельный онлайн-курс о том, как строить распределённые сервисы. Мы простым языком расскажем о DDD и об архитектуре больших систем. По итогам курса вы спроектируете распределённую систему, которую добавите в портфолио. О чем курс: Компании, которые уходят от монолитной архитектуры к сервисной и микросервисной, часто терпят поражение — получают такой же монолит, только разбитый по нескольким репозиториям. Мы расскажем, как избежать этих проблем — правильно разнести функциональность по сервисам и выбрать подходящий формат асинхронной коммуникации. Вы познакомитесь с Kafka, Event Streaming и понятием Schema Registry. Кроме того, мы упомянем о CQRS и SAGA. О чём курс На выходе получим полностью спроектированную систему, которая отвечает на все вопросы имплементации: разберёмся, какие данные нужны бизнесу, какие команды он хочет выполнять с ES like — подхода, а также составим модель данных, поймём, почему UML/ERD может быть избыточен. Урок 2 Переводим язык бизнеса в процессы и модель данных Урок 3 Переводим процессы и модель данных в сервисы и коммуникации Имплементация Выберем и сделаем механизм аутентификации. Отправим первое асинхронное сообщение, разберёмся в разнице между Distributed message Queue и Distributed log. А так как мы будем использовать kafka — разберёмся, как она работает на базовом уровне. На выходе получим первые два сервиса из проекта системы: SSO и первый сервис для бизнеса. А также свяжем их асинхронной коммуникацией для корректной работы всей системы. Урок 4 Первый сервис — authn в распределённых системах, CUD и Business events на практике Урок 5 Основной сервис инвентаризации, выбор message broker Дорабатываем систему Спроектируем логику для задачи, к которой система не приспособлена, — разберёмся с эволюцией событий и поймём, в каких случаях надо соблюдать прямую, а в каких — обратную совместимость. Сделаем, чтобы с нашей системой можно было спокойно спать ночью: разберёмся в тестировании, чтобы новые фичи ничего не ломали, и придумаем, как обеспечить устойчивость системы и обрабатывать невалидные или failure-события. На выходе разработаем план, что делать, когда изменение данных в событии потенциально может развалить всю систему. Также определим, как лучше тестировать асинхронную систему в каждом из случаев и что делать с событиями, которые сломались на уровне бизнес-логики или которые надо заретраить. Урок 7 После запуска: тестирование, ретраи и обработка ошибочных событий Урок 6 Добавляем незапланированный сервис: эволюция событий в системе Личный опыт и выводы Подведём итоги курса: поговорим о проблемах, которые Антон наблюдал в системах, мигрирующих на асинхронную коммуникацию. Это нейминг, проектирование, техническая реализация. Затронем data management patterns, чтобы показать, что это отдельные концепции, которые могут использоваться в асинхронной архитектуре, но не обязательно должны быть в ней. Обсудим, как практиковаться после курса и где искать идеи и места для новых проектов. На выходе: составим список подводных камней и советов, которые помогут избежать проблем. Получим цельную картину и шаги/темы для дальнейшего изучения. Урок 9 Итоги и что делать дальше Урок 8 Опыт Антона: 4 асинхронные системы из реальной жизни Тарифы: Теория — 9 видеоуроков — Факультатив по биллингу и модели данных в записи — Конспект самого главного — Список дополнительных материалов Практика — Домашка из 6 частей, без обратной связи Бонусы — Доступ к материалам после окончания курса — 4 месяца Пакет - Я сам

Четырёхнедельный онлайн-курс о том, как строить распределённые сервисы. Мы простым языком расскажем о DDD и об архитектуре больших систем. По итогам курса вы спроектируете распределённую систему, которую положите в портфолио как Software Architect.

Архитектура на основе асинхронности Это четырехнедельный веб-курс, который объясняет построение распределенных услуг. Мы простыми словами поговорим о DDD и структуре крупных систем. К концу курса вы разработаете распределенную систему, которую можно будет добавить в ваше портфолио. Контент курса: Организации, переходящие от монолитных структур к сервисной и микросервисной, часто сталкиваются с проблемой — получают монолит, разделенный на несколько репозиториев. Мы объясним, как избежать этих трудностей — правильно распределять функции между услугами и выбирать подходящий формат асинхронного обмена информацией. Вы познакомитесь с Kafka, Event Streaming и понятием Schema Registry, а также узнаете о CQRS и SAGA. Программа курса: Будет рассмотрено 6 этапов проектирования системы — от анализа бизнес-требований до связей между компонентами в системе. Узнаем, как получить данные, необходимые для работы бизнес-логики, из другого сервиса или части. По завершении этапа у вас будет полностью спроектированная система, отвечающая на все последующие вопросы реализации: поймем, какие данные нужны бизнесу, какие команды он хочет выполнить с подходом ES like, а также создадим модель данных и узнаем, когда UML/ERD может быть лишним. Урок 1: Переводим бизнес-язык в процессы и модели данных Урок 2: Преобразуем процессы и модели данных в сервисы и коммуникации Далее мы выберем и реализуем механизм аутентификации. Отправим первое асинхронное сообщение, разберемся в различиях между Distributed message Queue и Distributed log. И поскольку мы будем использовать kafka, узнаем, как она работает на базовом уровне. Наконец, создадим первые два сервиса из системного проекта: SSO и первую бизнес-службу. Также свяжем их асинхронным обменом сообщениями для правильной работы всей системы. Урок 3: Первый сервис — authn в распределённых системах, CUD и Business events на практике Урок 4: Основной сервис инвентаризации, выбор message broker Мы затем продолжим разработку системы. Создадим логику для задачи, к которой система не адаптирована, — разберемся с эволюцией событий и поймем, когда следует сохранять прямую и когда — обратную совместимость. Мы убедимся, что наша система позволяет спать спокойно ночью: разберемся в тестировании, чтобы новые функции не ломали существующие, и найдем способы обеспечить стабильность системы и обработки невалидных или failure-событий. По завершении этого блока мы разработаем стратегию для случаев, когда изменение данных в событии может потенциально разрушить всю систему. Также определим, как лучше тестировать асинхронную систему в каждой из ситуаций и что делать с событиями, которые нарушились на уровне бизнес-логики или которые требуют повторного выполнения. Урок 5: После запуска: тестирование, ретраи и обработка ошибочных событий Урок 6: Добавляем непредвиденный сервис: эволюция событий в системе В заключение мы подводим итоги курса: обсуждаем проблемы, которые Антон наблюдал в системах, переходящих к асинхронной коммуникации. Обсуждаем паттерны управления данными, чтобы показать, что это отдельные концепты, которые могут быть использованы в асинхронной архитектуре, но не обязательно должны быть в ней. Обсудим, как продолжить практику после курса и где искать идеи и возможности для новых проектов. По завершении составим список потенциальных сложностей и советов по их преодолению. Получим полное представление и шаги/темы для дальнейшего изучения. Урок 7: Итоги и следующие шаги Урок 8: Опыт Антона: 4 асинхронные системы из реальной жизни Тарифы: Теория — 9 видеозанятий — Факультатив по биллингу и модели данных в записи — Резюме ключевых моментов — Список дополнительных ресурсов Практика — Домашнее задание из 6 частей, без обратной связи Бонусы — Доступ к материалам после завершения курса — 4 месяца