- Регистрация
- 24.09.2021
- Сообщения
- 38 365
Чему вы научитесь 8 способов улучшить архитектуру при помощи CQRS Сходства и отличия CQRS и Vertical Slice Architecture Создание собственного CQRS движка Руководство по миграции с слоистой архитектурв на CQRS Handlers Выбор лучшего из существующих CQRS движков Разница в реализации сross-cutting concerns для слоистой архитектуры и CQRS 10 мифов о CQRS Разница в написании тестов для CQRS handlers и сервисов Стоит ли использовать Result для улучшения архитектуры или производительности Требования Базовые знания C# Описание Что такое CQRS Command Query Responsibility Segregation - это разделение системы на две независимых части: стек команд для изменения данных и стек запросов для выборки данных без их изменения. Стек команд рассчитан на работу с нормализованной реляционной базой через Object-Relational Mapping (ORM), а стек запросов - на денормализованное хранилище, оптимизированное на скорость выполнения выборок данных. Такой подход позволяет существенно повысить скорость выполнения выборок данных, которые составляют бОльшую часть операций на бэкенде. Зачем нужен еще один курс о CQRS Подход CQRS появился уже давно, но согласно исследованию InfoQ применяется на практике реже, чем микросервисы или DDD. Причина в том, что для улучшения производительностия сегодня чаще используются микросервисы вместо CQRS. А в использовании CQRS для улучшения архитектуры многие программисты не видят достоинств, и даже опасаются этого подхода. Данный курс покажет все достоинства для архитектуры системы, которые можно получить, используя вертикальные CQRS хендлеры вместо привычных горизонтальных сервисов. Таких достоинств будет целых восемь! Также мы опровергнем наиболее частые опасения, которые есть у программистов, планирующих переход на CQRS. О чем этот курс Курс начинается с наведения порядка в терминологии, разъяснения понятий CQS, CQRS, Vertical Slices и Feature by folder. Дальше на демо-приложении "интернет-магазин" мы будем рассматривать различия в реализации одного и того же функционала в горизонтальном слоистом и вертикальном CQRS вариантах. Пример будет сквозным, мы будет добавлять и изменять функционал демо-проекта и увидим на практике: Можно возвращать значения из команд Как выглядит реализация юскейса в ApplicationService и CQRS handler Обязательно ли использовать CQRS handlers для разделения стеков чтения и записи Стоит ли использовать ли CQRS команды и запросы как DTO или делать их отдельными классами Как массово регистрировать CQRS Handlers в DI Container Как переиспользовать код между юскейсами. Останутся ли ApplicationServices в системе, если application-логика реализована в виде CQRS handlers Как мигрировать приложение со слоев на хендлеры. Как ораганизовать процесс миграции и какие рефакторинги решарпера в этом помогут Как выглядит реализация CRUD сценариев для сервисов и хендлеров, какой подход лучше использовать Вызов юскейса из юскейса: неявное для сервисов и явное для хендлеров Cross-cutting concerns: реализация для сервисов и хедлеров Отличия в написании юнит-тестов для сервисов и хендлеров Стоит ли возвращать из хендлеров Result для улучшения архитектуры или производительности Мы рассмотрим отличия в реализации CQRS движка и приложения на его основе, когда из команд можно возвращать значения и когда этого делать нельзя. Мы сделаем обзор и анализ существующих CQRS движков, выберем лучший из них и обсудим, стоит ли использовать существующий CQRS движок или лучше написать свой собственный. Для кого этот курс? Курс предназначен для backend-разработчиков бизнес-приложений, которые хотят чувствовать гордость за проделанную работу, создавая системы, в которых добавление новых фич и исправление багов вызывает радость и счастье, а не боль и страдание. Демо-проект курса сделан на C# и ASP.NET Core, но без использования специфических фич как языка программирования, так и платформы. Так что идеи и подходы, описанные в курсе, будут понятны и полезны backend-разработчикам на любом языке программирования и любой платформе (Java, Python, JavaScript, Ruby, Go, PHP итд). Для кого этот курс: Middle и Senior разработчики Архитекторы Тимлиды и Техлиды CTO |