If you’ve been working in the .NET ecosystem for a while, chances are you’ve used AutoMapper and MediatR in at least one project.
They’re not just libraries anymore—they’ve become habits.
So when discussions around licensing started surfacing, it caught a lot of developers off guard. Not because of the cost alone, but because of how deeply these tools are embedded in modern .NET architecture.
This isn’t just about paying for a library. It’s about rethinking some of the assumptions we’ve been making for years.
How We Got Comfortable with These Libraries
Let’s be honest—AutoMapper and MediatR made our lives easier.
With AutoMapper, we stopped writing repetitive mapping code. No more manually copying properties between models. Just define a profile and move on.
With MediatR, we started writing cleaner, decoupled code. Controllers became thin. Business logic moved into handlers. Cross-cutting concerns like logging and validation became neatly pluggable.
At some point, these tools stopped feeling like “third-party libraries” and started feeling like part of .NET itself.
That’s where the risk begins.
The Moment Licensing Enters the Conversation
When a library shifts toward a license-based model, the first reaction is usually:
“Wait… do we now have to pay for this?”
But the more important question is:
“How dependent are we on this?”
Because for many teams, the answer is: very.
It’s Not Just About Cost
Yes, there’s a financial angle. But in most enterprise setups, the actual licensing cost is not the biggest issue.
The real impact shows up elsewhere:
- Procurement approvals
- Legal reviews
- Compliance tracking
- Budget planning across multiple services
For a single project, it’s manageable. For an organization with 20+ microservices? It adds up—both in cost and operational overhead.
The Bigger Concern: Architectural Lock-In
This is where things get interesting.
With AutoMapper
If your application heavily relies on mapping profiles:
Your DTO transformations are centralized
Your services assume mappings exist
Your tests indirectly depend on those configurations
Removing AutoMapper isn’t impossible—but it’s not trivial either.
You’re looking at:
- Rewriting mappings
- Refactoring services
- Potential regressions With MediatR
MediatR goes even deeper.
If you’ve built your system around it:
- Every request flows through IMediator
- Business logic lives in handlers
- Pipeline behaviors handle cross-cutting concerns Now imagine removing it.
You’re not just replacing a library—you’re reshaping your application flow.
A Subtle Reality Check
This situation exposes something important:
We didn’t just adopt these tools—we designed around them.
And that’s a key distinction.
There’s nothing wrong with using libraries. But when your architecture starts depending on them, you’re no longer just “using”—you’re committing.
So What Are the Options?
Most teams will end up choosing one of these paths:
1. Continue and Pay
For many teams, this is the simplest option.
- No refactoring
- No disruption
- Keep existing patterns
If your system is stable and heavily invested, this is a perfectly reasonable decision.
2. Gradually Move Away
Some teams will take this as an opportunity to reduce dependency.
For example:
- Replace AutoMapper in performance-critical paths
- Use explicit mapping where clarity matters
- Limit MediatR usage to specific layers This approach isn’t about abandoning the tools—it’s about using them more intentionally.
3. Replace Completely
This is the most aggressive approach.
- Manual mapping instead of AutoMapper
- Direct service calls or custom mediator instead of MediatR
You gain:
- Full control
Zero licensing concerns
But you also take on:More code
More responsibility
Less abstraction
An Unexpected Side Effect: Better Engineering Conversations
Interestingly, this shift is forcing teams to ask better questions:
- Do we really need AutoMapper here?
- Is MediatR adding value—or just structure?
- Are we optimizing for clarity, or just following patterns? These are conversations that often get skipped when everything is “free and working.”
Performance (The Thing We Often Ignore)
Let’s not forget—these tools do add overhead.
- AutoMapper uses reflection (though optimized over time)
- MediatR introduces an extra hop for every request In most applications, this is negligible.
But in high-throughput systems, it becomes noticeable.
Licensing discussions are pushing teams to revisit these trade-offs, which is actually a good thing.
What This Means for Clean Architecture & CQRS
A lot of people associate:
- AutoMapper → Clean Architecture
- MediatR → CQRS But that’s not entirely accurate.
These libraries *support * those patterns—they don’t define them.
You can implement:
- Clean Architecture without AutoMapper
- CQRS without MediatR It just takes a bit more effort.
And maybe that’s the real takeaway.
My Take
This shift isn’t a bad thing. It’s uncomfortable—but useful.
It reminds us that:
- No library is guaranteed to stay free forever
- Convenience always comes with a trade-off
- Good architecture should survive tool changes If replacing a library feels impossible, that’s usually a signal—not about the library, but about the design.
Final Thought
AutoMapper and MediatR are still great tools. That hasn’t changed.
What’s changing is how we think about them.
Not as default choices—but as deliberate ones.
And that’s a healthier place to be as engineers.
Top comments (0)