Как улучшить Enterprise архитектуру при помощи CQRS

Как выглядит реализация Query (юскейса, читающего данные, но не меняющего их) в случае горизонтальных сервисов

Как выглядит реализация Command (юскейса, меняющего данные) с возвращаемым значением в случае горизонтальных сервисов

Как выглядит реализация Command без возвращаемого значения в случае горизонтальных сервисов

Как выглядит реализация Query в случае хендлеров

Как выглядит реализация Command с возвращаемым значением в случае хендлеров

Как выглядит реализация Command без возвращаемого значения в случае хендлеров

Сравниваем между собой и выбираем наиболее удобный способ передачи DTO в команды и запросы

Как выглядит реализация Command c возвращаемым значением, когда архитектура CQRS движка не позволяет возвращать значения из команд

Выделение Read и Write стеков для слоистой архитектуры

Запрещаем менять данные в Read стеке для хендлеров

Массовая регистрация хендлеров в DI контейнере при помощи Scrutor

Переиспользования кода между разными юскейсами при помощи дополнительного сервиса в слоистой архитектуре

Переиспользования кода между разными юскейсами при помощи дополнительного сервиса для хендлеров

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

Какие плюсы хендлеров по сравнению с сервисами мы увиделив этом разделе. Какие мифы о CQRS были развенчаны. Какой вариант передачи данных из DTO в Request более удобен. Зачем кроме RequestHandler нам нужен еще и Request.

Какие рефакторинги ReSharper помогут в миграции с сервисов на хендлеры

Как организовать работу команды по миграции с сервисов на хендлеры

Выделяем базовый класс для сервисов в слоистой архитектуре

Создаем наследника от базового класса для сервисов

Выделяем базовые Query и QueryHandler для хендлеров

Выделяем базовые Command и CommandHandler для хендлеров

Как выглядит добавление команд и запросов для новой сущности Product в случае хендлеров

Как выглядит добавление нового юскейса "удалить сущность" в случае слоистой архитектуры

Как выглядит добавление нового юскейса "удалить сущность" в случае хендлеров

Как выглядит добавление нового юскейса "удалить сущность" в случае хендлеров, где из команд нельзя возвращать значения

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

К каким негативным последствиям приведет обобщение контроллеров при помощи generic-параметров

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

Как выглядит вызов юскейса из юскейса в случае сервисов и почему его трудно заметить

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

Добавляем диспетчер для удобного вызова юскейса из юскейса в случае хендлеров

Повышаем удобство использования диспетчера, вводя абстракцию IRequest, которая содержит тип возвращаемого из юскейса значения

Как выглядит реализаци диспетчера команд и запросов, когда из команд нельзя возвращать значения

Какие плюсы у сервисов по сравнению с хендлерами мы увидели в этом разделе. Чем отличается CQRS движок, если из команд разрещается или запрещается возвращать значения

Инфраструктурная задача "проверка прав доступа", которую нужно переиспользовать между разными юскейсами, которые могут быть как командами, так и рапросами, а также принадлежать разным сущностям

Что такое Cross-cutting-concerns, Аспектно-Ориентированное Программирование (АОП), какие есть варианты реализации АОП на платформе .NET

Достоинства и недостатки Fody.MethodDecorator для реализации cross-cutting concerns

Достоинства и недостатки Castle.DynamicProxy и AsyncInterceptor для реализации cross-cutting concerns

Достоинства и недостатки ASP.NET Core Filters для реализации cross-cutting concerns

Как реализовать удобный в использовании cross-cutting concern средствами CQRS-движка

Как реализовать cross-cutting concern при помощи паттерна Decorator для сервисов слоистой архитектуры

Как реализовать cross-cutting concern, когда CQRS-движок не позволяет возвращать значения из команд

Какие плюсы хендлеров по сравнению с сервисами мы увидели в этом разделе. Какой вариант реализации CQRS движка более удобен: позволяющий или запрещающий возвращать значения из команд

Чтобы протестировать юскейсы с учетом cross-cutting concerns, реализованных в виде AST.NET Core Filters, приходится генерировать HTTP запросы

Тестируем юскейсы с учетом cross-cutting concerns, реализованными средствами CQRS движка на уровне Application, в отрыве от фреймворков (не нужно генерировать HTTP запросы)

Сравниваем насколько проще писать тесты, когда application-логика реализована в виде хендлеров, а не сервисов, а cross-cutting concerns реализованы средствами CQRS движка, а не ASP.NET Core FIlters

Добавляем ASP.NET Core Middleware для возврата HttpStatusCode в случае генерации ожидаемого исключения NotFoundException

Сколько запросов в секунду обрабатывает бэкенд, если генерируются исключения

Сколько запросов в секунду обрабатывает бэкенд, если исключения не генерируются, а вместо них возвращается Result, который показывает была работа хендлера успешной или нет

Сравниваем результаты изменеий и делаем выводы стоит ли использовать Result как для увеличения производительности, так и для улучшения архитектуры

Изучаем самый популярный на сегодня CQRS движок, сравниваем его с собственной реализацией CQRS движка

Изучаем CQRS в реализации Грега Янга и сравниваем его вариант с современным видением

Сравниваем Brighter и Darked с MediatR

Изучаем еще один старый пример реализации CQRS (2012 год) и анализируем, насколько изменилось понимание CQRS за это время

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

Ищем и анализируем недостатки в архитектуре уровня Application, реализованном в виде CQRS хендлеров

Развенчиваем 10 наиболее популярных мифов о CQRS хендлерах

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