Bridge MediatR notifications to the Deveel Events publishing pipeline, and optionally surface incoming CloudEvents as MediatR notifications — so MediatR-native applications can adopt CloudEvents without restructuring existing handler code.
The problem today: Applications that already use MediatR as their in-process messaging bus must maintain two separate dispatch paths: one for MediatR INotification / IRequest handling and one for Deveel Events CloudEvent publishing. There is no standard hook that automatically intercepts a dispatched MediatR notification and routes it through the Deveel Events enrichment, middleware, and channel pipeline, nor any facility to surface an inbound CloudEvent as a MediatR notification so that existing INotificationHandler<T> implementations can react to it without change.
What we will build: A Deveel.Events.Publisher.MediatR package providing:
- A MediatR
INotificationHandler<TNotification> base implementation — and an opt-in IPipelineBehavior<TRequest, TResponse> for request-side interception — that detects notifications annotated with [Event] (or implementing a configurable marker interface) and forwards them to IEventPublisher as CloudEvents, applying the full enrichment, middleware, and channel dispatch pipeline.
- A
CloudEventNotificationMapper that translates between INotification and CloudEvent, deriving the CloudEvents type, source, and subject from annotation metadata (compatible with the existing [Event] and [EventProperty] attribute model) or from a configurable mapping delegate.
- An inbound bridge: an
IEventSubscription handler that receives CloudEvents from the subscription registry and re-publishes them as MediatR INotification objects through the IMediator pipeline, so that existing INotificationHandler<T> implementations react to external events with no code changes.
AddMediatREventPublisher() and AddMediatREventConsumer() DI registration extensions, fully compatible with the standard MediatR.Extensions.Microsoft.DependencyInjection / MediatR v12+ registration pattern.- A test helper that captures CloudEvents emitted by MediatR notifications, compatible with the
Deveel.Events.TestPublisher infrastructure.
Benefits:
- MediatR-native applications can adopt Deveel Events incrementally: annotate an existing
INotification and it begins flowing through the full CloudEvents pipeline — enrichment, schema validation, middleware, dead-letter — without restructuring any handler or command code.
- The pipeline-behavior and notification-handler interception points mean cross-cutting concerns (logging, tracing, schema validation) are applied consistently whether the CloudEvent originates from a MediatR notification or from a direct
IEventPublisher call.
- The inbound bridge allows consumer-side handlers to remain written as standard
INotificationHandler<T>, fully independent of the broker transport that delivered the event (RabbitMQ, Azure Service Bus, webhook, etc.).
- No lock-in: the integration is purely additive — removing the package leaves both the MediatR handler tree and the Deveel Events pipeline fully functional and independently operable.
- Works seamlessly with the middleware pipeline, schema validation, OpenTelemetry tracing, and the dead-letter channel, inheriting all cross-cutting capabilities with zero additional configuration.
The problem today: Applications that already use MediatR as their in-process messaging bus must maintain two separate dispatch paths: one for MediatR
INotification/IRequesthandling and one for Deveel Events CloudEvent publishing. There is no standard hook that automatically intercepts a dispatched MediatR notification and routes it through the Deveel Events enrichment, middleware, and channel pipeline, nor any facility to surface an inbound CloudEvent as a MediatR notification so that existingINotificationHandler<T>implementations can react to it without change.What we will build: A
Deveel.Events.Publisher.MediatRpackage providing:INotificationHandler<TNotification>base implementation — and an opt-inIPipelineBehavior<TRequest, TResponse>for request-side interception — that detects notifications annotated with[Event](or implementing a configurable marker interface) and forwards them toIEventPublisheras CloudEvents, applying the full enrichment, middleware, and channel dispatch pipeline.CloudEventNotificationMapperthat translates betweenINotificationandCloudEvent, deriving the CloudEventstype,source, andsubjectfrom annotation metadata (compatible with the existing[Event]and[EventProperty]attribute model) or from a configurable mapping delegate.IEventSubscriptionhandler that receives CloudEvents from the subscription registry and re-publishes them as MediatRINotificationobjects through theIMediatorpipeline, so that existingINotificationHandler<T>implementations react to external events with no code changes.AddMediatREventPublisher()andAddMediatREventConsumer()DI registration extensions, fully compatible with the standardMediatR.Extensions.Microsoft.DependencyInjection/MediatRv12+ registration pattern.Deveel.Events.TestPublisherinfrastructure.Benefits:
INotificationand it begins flowing through the full CloudEvents pipeline — enrichment, schema validation, middleware, dead-letter — without restructuring any handler or command code.IEventPublishercall.INotificationHandler<T>, fully independent of the broker transport that delivered the event (RabbitMQ, Azure Service Bus, webhook, etc.).