Capabilities
Mediator & CQRS
One message, one handler, one pipeline — vertical slices with uniform cross-cutting concerns.
The mediator is Relay’s front door. Instead of controllers calling service classes, every operation is a typed message dispatched through a pipeline — which means validation, authorization, logging and transactions are written once and applied to everything.
What ships: commands and queries with typed buses (ICommandBus,
IQueryBus), FluentValidation-style validators, prioritized pipeline behaviors,
DDD building blocks (AggregateRoot<TId>, Entity<TId>, ValueObject,
Guard), domain and integration events, attribute-generated HTTP endpoints with
ProblemDetails error mapping and pagination, and source analyzers that catch
missing/duplicate handlers at build time.
Start with the quickstart if you haven’t, then work through the articles below in order — they build the same service up from one command to a full domain model.
Learn by building
The tutorials for this area, in order — each with a runnable sample.
001Getting Started: Commands, Queries, and the MediatorRelay is a framework for building .NET services around CQRS (Command Query Responsibility Segregation) and an in-process mediator.
002Your First AggregateIn article 001 the Product was a plain record and the "store" was a dictionary.
003Domain EventsIn article 002 the Order aggregate raised domain events, but they just sat in a list — nothing reacted to them. This article closes that loop.
004Errors & HTTPA handler's job is to express what went wrong in business terms — "this payment was not found," "the amount exceeds the limit," "the card was declined" — not to know that those map to HTTP 404, 422, and 402.