mediator-commands-queries

Standardize MediatR command and query use cases under Application.UseCases folders.

Updated Apr 9, 2026
One-click install
npx skills add https://github.com/SergeuMatyasov/dotnet-shared-skills --skill mediator-commands-queries
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: mediator-commands-queries
Source: https://github.com/SergeuMatyasov/dotnet-shared-skills/tree/main/mediator-commands-queries
Command: npx skills add https://github.com/SergeuMatyasov/dotnet-shared-skills --skill mediator-commands-queries

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Standardize MediatR command and query use cases to enforce clear write/read boundaries and keep use-case logic in a single cohesive folder, preventing code from scattering across Commands, Queries, and Handlers.

Core Features & Use Cases

  • Unified case structure: every use case lives in one UseCases/<Feature>/<CaseName> folder.
  • Validator separation: validators live in separate files within the same case folder.
  • CQRS discipline: commands model write intent, queries model read-only operations, and handlers orchestrate the flow without leaking domain logic.
  • Correct navigation and governance: namespaces map to feature and case, not to technical layers.

Quick Start

Create a new MediatR use case under UseCases/<Feature>/<CaseName>/ following the standard naming and folder structure.

Frequently Asked Questions about mediator-commands-queries

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I structure MediatR use cases to enforce clear CQRS boundaries in .NET?▼

MediatR use cases enforce CQRS boundaries by keeping each command and query in a single cohesive UseCases/<Feature>/<CaseName> folder, separating validators into distinct files, and mapping namespaces to features instead of technical layers like Commands or Handlers.

What is the best way to organize MediatR commands, queries, and handlers?▼

The best way to organize MediatR commands and queries is grouping them by use case rather than technical function. Each use case lives in a single cohesive folder under Application.UseCases, preventing cross-cutting folders and keeping related logic together.

Why does my MediatR use case logic scatter across Commands, Queries, and Handlers folders?▼

MediatR use case logic scatters when you split Commands, Queries, and Handlers into separate cross-cutting folders. Standardizing on a single UseCases/<Feature>/<CaseName> folder structure keeps all related logic cohesive and prevents code fragmentation.

How do I separate validators in a MediatR CQRS project without cluttering the handler?▼

To separate validators in a MediatR CQRS project, place each validator in a separate file within the same use case folder. This keeps validation logic isolated from the handler while maintaining the cohesive folder structure under Application.UseCases.

Can I migrate existing MediatR commands and queries into a standardized CQRS folder structure?▼

Yes, you can migrate existing MediatR commands and queries into a standardized CQRS folder structure. Moving use cases under Application.UseCases/<Feature>/<CaseName> ensures one request per use case, proper naming, namespace structure, and shared CQRS abstractions.

What architecture rules should MediatR handlers follow in a CQRS application?▼

MediatR handlers in a CQRS application should orchestrate flow without leaking domain logic, propagate cancellation tokens, use shared CQRS abstractions, and follow strict architecture rules ensuring commands model write intent and queries model read-only operations.