♻️Switch from MediatR to more performant source-generated MIT-licensed version - Mediator

Cc: @danielmackay @wicksipedia @GordonBeeming

Hi guys,

Should we consider switching SSW.CleanArchitecture from MediatR to the source-generated Mediator library?

https://github.com/martinothamar/Mediator

Pain

MediatR v13+ has moved from Apache 2.0 to a dual commercial/OSS licensing model and now supports/requires license key configuration.

This creates a few concerns for an enterprise template:

• Commercial/proprietary projects may need to make an explicit licensing decision before using the template.
• The template may unintentionally introduce a paid/commercial dependency into new client projects.
• Users may need to pin to older MediatR versions or manage license keys.
• This adds friction for greenfield projects using SSW.CleanArchitecture.

martinothamar/Mediator appears to be a strong alternative because it is:

• MIT licensed
• Source-generated
• High performance
• Similar in concept/API to MediatR
• Native AOT friendly
• Suitable for CQRS-style request/handler patterns

What code could be improved?

Review places where SSW.CleanArchitecture depends on MediatR abstractions, including:

• Commands
• Queries
• Notifications/events
• Pipeline behaviours
• Validation behaviours
• Logging behaviours
• Exception handling behaviours
• Dependency injection registration

Likely areas:

• Application layer request/handler abstractions
• Web/API endpoint usage of ISender / IMediator
• DI registration for MediatR
• Template-generated command/query examples
• Tests that rely on MediatR types

Tasks

• Review current MediatR usage in SSW.CleanArchitecture.
• Compare required features against martinothamar/Mediator.
• Confirm support for request/response handlers.
• Confirm support for notifications/events if used by the template.
• Confirm support for pipeline behaviours.
• Confirm support for validation behaviours.
• Confirm support for exception handling patterns.
• Confirm DI registration approach.
• Confirm impact on generated template code.
• Confirm impact on existing tests.
• Create a small proof of concept branch replacing MediatR with Mediator.
• Benchmark or sanity-check startup/runtime impact.
• Document any breaking changes for consumers.
• Decide whether to switch fully, support both, or stay on MediatR.
• If switching, add an ADR explaining the decision.

More Information

MediatR v13 introduced dual commercial/OSS licensing and license key support:

https://github.com/LuckyPennySoftware/MediatR/releases/tag/v13.0.0

MediatR commercial licensing:

https://mediatr.io/

Mediator:

https://github.com/martinothamar/Mediator

Mediator describes itself as:

A high performance .NET implementation of the Mediator pattern using source generators.

Potential benefits for SSW.CleanArchitecture:

• Avoid introducing commercial licensing concerns into new projects
• Better default choice for enterprise/client templates
• Better performance from source generation
• Better Native AOT compatibility
• Lower runtime reflection/registration overhead
• Keeps the Clean Architecture/CQRS style without depending on MediatR

Screenshots

N/A

Thanks!

Start by inventorying MediatR usage across the application layer, Web/API endpoints, dependency-injection registration, generated template code, and tests. Compare those usages with Mediator, then evaluate the proof-of-concept, compatibility, benchmarks, and breaking changes; done means a documented decision, with an ADR if the project switches.