Proposal: Decoupling Mediator dependency from Ardalis.SharedKernel

Hi Steve (@ardalis),

I’ve been a long-time follower of your work on Clean Architecture and DDD, and I frequently use your libraries in my professional projects.

I’m reaching out because I’ve deeply explored these patterns myself: I developed a custom framework for the enterprise company I work for, and I’ve published an open-source library called **Concordia.Core**.

**Concordia.Core** was specifically designed as a high-performance alternative to MediatR, leveraging **C# Source Generators** to eliminate runtime reflection—a common pain point in large-scale Clean Architecture solutions.

Given our shared interest in architectural purity and performance, I’d like to propose an evolution for **Ardalis.SharedKernel**: removing the direct dependency on MediatR (or any specific Mediator implementation).

The goal would be to make the SharedKernel even more agnostic. We could collaborate on a dedicated, lightweight abstraction, allowing users to:
1. Keep the SharedKernel lean and dependency-free.
2. Plug in their preferred messaging implementation (be it MediatR, a Source Generator-based one like Concordia, or a custom one) without pulling in extra overhead.

I would be honored to share the insights I gained while building Concordia.Core and enterprise-grade frameworks to help create a more decoupled messaging approach for the kernel.

What are your thoughts on this?

Best regards,

Luca (@lucafabbri)

The proposal does not name files, tests, or entry points. Start by reviewing the repository’s current MediatR dependency and project configuration; done would require an agreed abstraction and an approved plan for decoupling it.

Written by the indexing model from the issue text.