Как по мне тут так же может быть два слоя валидации, доменная и самих реквестов. История с исключениями поможет при доменной валидации, когда у вас есть сервис обрабатывающий доменную логику, например в доменной библиотеке и вам надо прокинуть ошибку наверх.
Конкретно в данном примере так и есть, но это только базовое использование этого подхода, где у вас query и command в одном приложении, дальше это расширяться может до бесконечности.
в полной версии у вас может быть три отдельных приложения, одно выполняет по сути crud сырых данных, приложение которое занимается чтением подготовленных данных для вывода, в том числе сложных объектов, которые при выводе требуют много джоинов и пр и приложение синхронизатор, который с помощью eventsourcing будет реагировать на изменения в сырых данных и обновлять подготовленные, таким образом мы сможем реплицировать только query часть, так как она и является наиболее загруженной в сервисах для вывода контента
данная статья это скорее туториал, как реализовать самый простой CQRS в вашем приложении в рамках ASP.NET Core 5 и некая точка для сбора фидбэка, чтобы понять, что людям хочется узнать. В вашем случае вы изолируете всё в подсистемы, но ваша подсистема может так же распухать как и контроллер и репозиторий, и точно также могут распухать и её зависимости, CQRS помогает избежать именно этого. в дальнейших статьях будут рассмотрены более сложные реализации, когда одно приложение выступает в качестве обработчика команд и кладет сырые данные в бд, а второе будет приложение будет возвращать вам подготовленные для вывода данные.
Как по мне тут так же может быть два слоя валидации, доменная и самих реквестов. История с исключениями поможет при доменной валидации, когда у вас есть сервис обрабатывающий доменную логику, например в доменной библиотеке и вам надо прокинуть ошибку наверх.
У Дино Эспозито есть презентация на эту тему https://youtu.be/CrBi33fpFh4
Конкретно в данном примере так и есть, но это только базовое использование этого подхода, где у вас query и command в одном приложении, дальше это расширяться может до бесконечности.
в полной версии у вас может быть три отдельных приложения, одно выполняет по сути crud сырых данных, приложение которое занимается чтением подготовленных данных для вывода, в том числе сложных объектов, которые при выводе требуют много джоинов и пр и приложение синхронизатор, который с помощью eventsourcing будет реагировать на изменения в сырых данных и обновлять подготовленные, таким образом мы сможем реплицировать только query часть, так как она и является наиболее загруженной в сервисах для вывода контента