
<Sponsorships>

[**Build Faster with ABP.IO Modules**](https://abp.io/modules?utm_source=newsletter&utm_medium=affiliate&utm_campaign=milanjovanovic_apr19).
Save weeks of development time with ready-made, enterprise-grade modules from ABP.IO.
From Identity and SaaS to Audit Logging and Language Management, ABP's modular architecture helps you ship faster and scale confidently — all within your favorite .NET ecosystem.
Each module is fully integrated, tested, and production-ready — so you can focus on building what makes your web app unique.
➡️ [**Explore the full list**](https://abp.io/modules?utm_source=newsletter&utm_medium=affiliate&utm_campaign=milanjovanovic_apr19)!

A great auth product gets out of your way.
[**PropelAuth**](https://www.propelauth.com/?utm_source=newsletter&utm_campaign=mj)
makes it easy to [**add authentication to your .NET application**](https://docs.propelauth.com/guides-and-examples/guides/dot-net-oauth-guide/?utm_source=newsletter&utm_campaign=mj) -
no digging through obscure documentation or frantically searching StackOverflow for answers.
Whether you're supporting small businesses or huge enterprises, PropelAuth has everything you need: organization management, RBAC, MFA, Enterprise SSO and more.

</Sponsorships>

I've been revisiting Sam Newman's excellent book ["Monolith to Microservices"](https://www.oreilly.com/library/view/monolith-to-microservices/9781492047834/) recently,
and it's reminded me just how transformative this architectural approach can be **when applied correctly**.

As someone who's implemented microservices in various organizations, I wanted to share some valuable insights I've gained through both study and practical experience.

What exactly are microservices, and why might they be the right architectural choice for your organization?

Let's dive into the core concepts and benefits of microservices architecture.

## What Are Microservices?

Microservices are **independently deployable** services modeled around a **business domain**.
Business domain is key here, but more on that later.
They communicate with each other via networks and offer many options for solving complex architectural problems.

Think of microservices as small, focused teams rather than a large department.
Each team has a specific responsibility, operates somewhat independently, and communicates clearly with other teams when needed.
Instead of one massive codebase that handles everything, you have multiple smaller codebases, each focusing on a specific business capability.

<Image
  src="blogs/mnw_138/microservices_architecture.png"
  width={2115}
  height={1591}
  alt="Microservices architecture showing an event management system."
/>

As Sam Newman defines them in "Monolith to Microservices":

> Microservices are independently deployable services modeled around a business domain.
> They communicate with each other via networks, and as an architecture choice offer many options for solving the problems you may face.

Microservices give you a strategy to design a modular system and decompose it into bounded contexts.
However, the problem I often see is that developers use microservices to enforce code boundaries.
This is a mistake.
We'll fix that in a moment.

## Key Characteristics of Microservices

Let's explore some of the key characteristics that define microservices:

### Independent Deployability

You can make changes to a microservice and deploy it to production without having to deploy anything else.
This isn't just a theoretical ability - it's a discipline you practice for most of your releases.

The value here is significant: **smaller deployments** carry **less risk**, enable **faster release cycles**, and allow teams to test their changes in isolation.

When a critical bug appears in one service, you can fix and deploy just that service rather than orchestrating a full system release.
This is especially valuable in large systems where coordinating releases can be a logistical nightmare.

### Business Domain Focus

Microservices are organized around [**business capabilities**](screaming-architecture) rather than technical layers.
Instead of having separate frontend, backend, and database teams (and the coordination that requires),
you might have teams dedicated to "Event Management," "Customer Accounts," or "Attendance."

This alignment makes it easier to implement business functionality changes since all the related code - from UI to data storage - is grouped together.
When a business requirement changes, you can often change just one service rather than coordinating changes across multiple layers.

<Image
  src="blogs/mnw_138/event_storming.png"
  width={2534}
  height={876}
  alt="Event storming whiteboard with events grouped into logical boundaries."
/>

### Data Ownership

Microservices **encapsulate data storage** and retrieval, exposing data only via [**well-defined interfaces**](internal-vs-public-apis-in-modular-monoliths).
Databases are hidden inside the service boundary rather than shared between services.

This stands in stark contrast to traditional approaches where multiple applications share a common database, often leading to tight coupling and risky schema changes.

When a service owns its data exclusively, it can:

- Evolve its internal data model without breaking other services
- Implement the most appropriate storage technology for its needs
- Provide a stable API for other services to access its data.

It's not uncommon for multiple services to share the same database, but you're giving up some of the benefits of microservices by doing so.
In practice, one database per service is the most common approach.

### Network Communication

Services communicate with each other via networks, making microservices a form of distributed system.
This network-based communication could use [**REST APIs**](/pragmatic-rest-apis), message queues, gRPC, GraphQL, or other protocols depending on the specific needs.

<div className="centered">
  <Image
    src="blogs/mnw_138/network_communication.png"
    width={736 * 0.7}
    height={372 * 0.7}
    alt="A simple diagram with two boxes representing microservices that communicate over a network."
  />
</div>

This explicit communication over networks allows services to be deployed independently and even run on different infrastructure.
But it also means dealing with network latency, potential failures, and serialization concerns.

Teams building microservices need to carefully design their [**inter-service communication patterns**](modular-monolith-communication-patterns)
to balance performance, reliability, and flexibility.

## The Origins of Microservices

The term "microservices" has an interesting origin story.
In 2011, a software consultant named James Lewis became interested in what he called "micro-apps" - small services optimized to be easily replaceable.

The distinguishing feature was how small in scope these services were.
Some could be written or rewritten in just a few days.
As discussions evolved, the term "microservices" was adopted since these weren't self-contained applications but rather services working together.

It's worth noting that while "micro" is in the name, the size of a microservice isn't its defining characteristic.
Rather, it's about having services with well-defined boundaries that can be developed, deployed, and scaled independently.

## Key Benefits of Microservices

What are the benefits of adopting a microservices architecture?

Why should you consider it for your organization?

Let's explore some of the key advantages:

### Flexibility and Adaptability

**Microservices give you options**.
They provide flexibility in how you can scale, evolve, and maintain your system over time.

- When business requirements change, you can modify just the affected services rather than risking changes to the entire system.
- New capabilities can be introduced as new services without disrupting existing functionality.
- As your understanding of the domain grows, service boundaries can evolve to better reflect that understanding.

This ability to evolve incrementally is particularly valuable in rapidly changing business environments where time-to-market is critical.

### Technology Diversity

With microservices, you can mix and match technology stacks.
Each service can use the programming language, database, or framework best suited for its specific requirements.
This practice is known as polyglot programming and [**polyglot persistence**](modular-monolith-data-isolation).

For example, a recommendation engine might use Python with specialized machine learning libraries.
On the other hand, a transaction processing service might use .NET for its strong typing and performance characteristics.

A reporting service might use a columnar database optimized for analytics,
while a user profile service could use a document database that better fits its data model.

<div className="centered">
  <Image
    src="blogs/mnw_138/polyglot_persistence.png"
    width={639 * 0.5}
    height={746 * 0.5}
    alt="Event storming whiteboard with events grouped into logical boundaries."
  />
</div>

This flexibility allows teams to choose the right tool for each job rather than compromising on a one-size-fits-all approach.

### Parallel Development

Multiple teams can work on different services simultaneously without stepping on each other's toes.
This parallelization can significantly accelerate development velocity in larger organizations.

Each team can maintain its own release schedule, make technology decisions, and optimize for their specific service's needs without coordinating with every other team.
I've seen firsthand how this autonomy can reduce dependencies between teams, minimizing bottlenecks and wait times.

Organizations commonly structure their teams around services or groups of related services.
You might know this concept as [Conway's Law](https://en.wikipedia.org/wiki/Conway%27s_law):

> Organizations, who design systems, are constrained to produce designs which are copies of the communication structures of these organizations.

### Targeted Scaling

You can scale just the services that need it, rather than scaling the entire system.
This provides more efficient resource utilization and can reduce operational costs.

For example, if your product catalog needs to handle high traffic during a sale, you can scale just the catalog service without scaling your payment processing service.

This granular scaling becomes especially valuable as systems grow and different components have different performance characteristics.
Some services might be CPU-intensive while others are memory-intensive, and with microservices, you can optimize the infrastructure for each service's specific needs.

This approach can lead to significant cost savings compared to [**scaling a monolith**](scaling-monoliths-a-practical-guide-for-growing-systems),
where all components must scale together regardless of their individual requirements.

### Organizational Alignment

Microservices can help align your technical architecture with your organizational structure.
Teams can own specific services that correspond to their business domain expertise, promoting clearer ownership and accountability.

<div className="centered">
  <Image
    src="blogs/mnw_138/evently_domain.png"
    width={2506 * 0.25}
    height={1282 * 0.25}
    alt="UML diagram showing the main bounded contexts in the system and their parts."
  />
</div>

This alignment reduces handoffs and coordination costs between teams, as each team has clear boundaries of responsibility.
It supports Conway's Law in a positive way.
Instead of having your communication structure accidentally create your architecture, you deliberately design both your teams and your services around business capabilities.

This approach can lead to more stable team structures and software boundaries over time, as business domains tend to evolve more slowly than technical implementations.

## Challenges to Consider With Microservices

While microservices offer numerous benefits, they're not without challenges:

### Distributed System Complexity

Network communication introduces latency, reliability challenges, and makes debugging more difficult.
Services must handle network failures gracefully, implement retries with backoff strategies,
and deal with the reality that a request might succeed but the response might get lost.

[**Distributed tracing**](introduction-to-distributed-tracing-with-opentelemetry-in-dotnet) becomes essential to understand how requests flow through the system.

<Image
  src="blogs/mnw_138/distributed_trace.png"
  width={1920}
  height={850}
  alt="Distributed trace."
/>

You'll need to develop strategies for handling partial system failures.
Concepts like circuit breakers and bulkheads become part of your everyday vocabulary.

### Operational Overhead

Managing many services requires robust [**deployment pipelines**](streamlining-dotnet-9-deployment-with-github-actions-and-azure), monitoring, and debugging tools.
You'll need to invest in automation for deployment, [**health checking**](health-checks-in-asp-net-core), scaling,
and perhaps [**service discovery**](how-dotnet-aspire-simplifies-service-discovery).
Each service needs monitoring, logging, and alerting.

This overhead can be substantial.
Organizations successfully running microservices typically have a strong DevOps culture and tooling to manage this complexity.

### Data Consistency

Maintaining consistency across service boundaries becomes more challenging without the safety of [**database transactions**](working-with-transactions-in-ef-core).

Implementing business processes that span multiple services often requires eventual consistency models and compensation mechanisms to handle failures.
You'll need to design your services with [**idempotency**](implementing-idempotent-rest-apis-in-aspnetcore) in mind and may need to implement patterns like the
[**Saga pattern**](implementing-the-saga-pattern-with-masstransit) to manage distributed transactions.

These approaches add complexity but can actually lead to more resilient systems when implemented correctly.

### Service Coordination

Orchestrating workflows that span multiple services requires careful design.
Simple processes in a monolith can become complex choreographies in a microservice architecture.

You'll need to decide whether to use [**orchestration**](orchestration-vs-choreography) (where a central service directs the process)
or [**choreography**](orchestration-vs-choreography) (where services react to events without central coordination).
These patterns have different trade-offs in terms of coupling, resilience, and observability.

Designing these cross-service workflows often reveals subdomain boundaries you might have missed in initial modeling.

## Key Takeaway

From my experience, the most important thing to remember is that microservices ultimately **buy you options**.
They provide flexibility but come with costs.

Are these costs worth the options you want to exercise?

For organizations with a large engineering team working on a complex system that needs to evolve quickly, microservices may be worth the overhead.
For smaller teams or systems with more stable requirements, a [**well-designed monolith**](what-is-a-modular-monolith) might be more appropriate.
Forget about resume-driven development for a moment.
It's about what solves your specific problems with **acceptable trade-offs**.

In my work, I've found that the most successful microservice adoptions start small, often by breaking off just one or two services from a monolith.
Then, gradually expanding as the organization builds the necessary skills and infrastructure.
This evolutionary approach reduces risk and allows teams to learn as they go.

I always like to reflect on these questions:

1. What parts of the current architecture would benefit most from independent deployability?
2. What challenges might the organization face when adopting microservices?
3. How well does the current system align with business domains?

If you want to dive deeper into building microservices - but starting from a monolith, check out [**Modular Monolith Architecture**](/modular-monolith-architecture).
There's an entire chapter dedicated to developing microservices, including advanced techniques such as API gateways, using message queues, and system integration testing.

Thanks for reading.

And stay awesome!

---



<Sponsorships>

Developers must start adopting AI in their daily workflow to be competitive,
which is why Dometrain just launched a [**Deep Dive into Boosting Developer Productivity with AI**](https://dometrain.com/course/deep-dive-boosting-developer-productivity-with-ai/?ref=milan-jovanovic&promo=newsletter-20250412&coupon_code=BIRTHDAY2).
From Claude Sonnet to GPT4o and from ChatGPT to any IDE, this new Dometrain course will ensure your productivity and competitiveness in the market.
Use code BIRTHDAY2 at checkout for 40% off.
[**Get it at 40% off**](https://dometrain.com/course/deep-dive-boosting-developer-productivity-with-ai/?ref=milan-jovanovic&promo=newsletter-20250412&coupon_code=BIRTHDAY2)!

[**Hey .NET devs, can your AI Agent do this**](https://fnf.dev/4hzFtNz)?

- Add new features spanning multiple files
- Queue up tests for you in the terminal
- Open Linear tickets, start a pull request
- Start a new branch in GitHub from recent commits

Augment Code's new AI Agent can. [**Try it in VS Code now**](https://fnf.dev/4hzFtNz)!

</Sponsorships>

**Vector search** is changing how we find information.
Unlike old search methods that look for exact words, vector search finds content based on meaning.
This makes search results more helpful and human-like.

When you search for "quick healthy breakfast ideas," vector search can find articles about "nutritious morning meals" even if they don't use your exact words.
This happens because vector search understands what you mean, not just what you type.

In this week's newsletter, we'll break down how vector search works and why it's important.

## Understanding Vector Embeddings

At the heart of vector search are **vector embeddings**.
These are lists of numbers that represent data.
But how do we get from words or images to numbers?

Here's how it works:

1. We feed text, images, or other data into a [**large language model (LLM)**](working-with-llms-in-dotnet-using-microsoft-extensions-ai)
2. The LLM turns each piece of data into a list of numbers (a vector)
3. These numbers capture the meaning of the data
4. Similar things get similar number patterns

<div className="centered">
  <Image
    src="blogs/mnw_137/vector_space.png"
    width={1719 * 0.3}
    height={1937 * 0.3}
    alt="Vector space visualization."
  />
</div>

Think of each number in the vector as describing one aspect of the data.
With hundreds or thousands of these numbers, vectors can capture complex meanings and relationships.

For example, in vector form, the words "lion" and "bobcat" would have similar number patterns because they refer to similar animals.
Meanwhile, "cat" would have a different pattern, though still somewhat similar since it's also a feline.

## How Vector Search Works

When you search using vector search:

1. Your search question gets turned into a vector
2. The system compares this vector to all the vectors in its database
3. It finds the vectors that are most similar to your search vector
4. It returns the data connected to those similar vectors

To find similar vectors, the system measures how close they are to each other.
Think of each vector as a point in space - the closer two points are, the more similar their meanings.

<Image
  src="blogs/mnw_137/vector_search.png"
  width={2487}
  height={786}
  alt="Vector search visualization."
/>

### Vector Databases

To make vector search work well with lots of data, we need special storage systems called **vector databases**.
These databases are built to store and quickly search through millions or billions of vectors.

Vector databases do more than just store vectors - they organize them in smart ways that make searching faster.
They use special methods called "Approximate Nearest Neighbor" (ANN) algorithms that can find similar vectors without checking every single one in the database.

<figure className="figure-center">
  <div className="bordered">
    <Image
      src="blogs/mnw_137/vector_databases_landscape.png"
      width={1400}
      height={832}
      alt="Vector databases landscape."
    />
  </div>
  <figcaption>
    Source: [What are Vector Databases? A Beginner's
    Guide](https://www.infracloud.io/blogs/vector-databases-beginners-guide/)
  </figcaption>
</figure>

These databases also store the original content along with its vector, so when you get search results,
you see the actual text, images, or other data you were looking for.
Popular vector databases include Weaviate, Pinecone, and Qdrant.
But you can also turn PostgreSQL into a vector database using the pgvector extension.

The combination of vector embeddings and vector databases makes search extremely fast, even with millions of items to search through.
This speed makes vector search practical for real-world applications where users expect instant results.

## Key Differences from Traditional Search

Traditional keyword search works like this:

- You type "red shoes"
- The system finds pages with the words "red" and "shoes"
- Results that mention these words more often rank higher

This approach has problems:

- It misses related terms ("scarlet footwear")
- It doesn't understand context
- It can't handle questions well

An improvement to keyword search is [**full-text search**](how-i-implemented-full-text-search-on-my-website), which looks at the whole text of documents.
However, this still has some shortcomings that vector search solves.

Vector search fixes these issues by focusing on meaning rather than exact words.
It can:

- Find content with related concepts
- Understand the context of your search
- Return helpful results even for complex questions

This is why vector search powers many modern AI applications.
It helps chatbots find relevant information and makes recommendation systems more accurate.

## Summary

Vector search represents a major step forward in how computers understand and retrieve information.
By converting data into number patterns that capture meaning, vector search can find connections that keyword search would miss.

This technology is behind many of the smart search features we now take for granted -
from finding similar products in online stores to helping AI assistants answer our questions.
As AI continues to advance, vector search will play an increasingly important role in helping us navigate the growing sea of digital information.

While not perfect, vector search bridges the gap between how computers store data and how humans think about meaning -
making our digital tools more helpful and intuitive to use.

In a future newsletter, we'll dive into the practical side of vector search.
You'll learn how to implement your own vector search system using popular tools and libraries, with step-by-step code examples and best practices.

That's all for today.

See you next week.

---



<Sponsorships>

Stack traces > “it just broke” — [**Sentry for .NET**](https://sentry.io/for/dot-net/?utm_source=dotnetweekly&utm_medium=paid-community&utm_campaign=errors-fy26q1-evergreen&utm_content=newsletter-itbroke-trysentry)
gets it.
NullReferenceException: object not set to an instance of anything remotely helpful.
Sentry captures the full error, request, and user context so you can stop debugging production like it's a murder mystery.
👉 [**Start fixing with Sentry — free trial, no guessing**](https://sentry.io/for/dot-net/?utm_source=dotnetweekly&utm_medium=paid-community&utm_campaign=errors-fy26q1-evergreen&utm_content=newsletter-itbroke-trysentry).

Sure, you can roll your own auth - if you hate free time.
If you're done doing auth on your own, don't sacrifice your control.
[**FusionAuth**](https://fnf.dev/4jDQajN) is downloadable, and can be developed and tested locally.
A single-tenant architecture provides better scale and security than a purely multi-tenant SaaS model,
even if you deploy via the cloud.
[**Try it for free**](https://fnf.dev/4jDQajN), and check out our transparent pricing!

</Sponsorships>

Big changes are happening in the .NET ecosystem.
Three powerhouse libraries - MediatR, AutoMapper, and MassTransit - are moving to commercial licenses.
Not so long ago, Fluent Assertions also announced its plans to move to a commercial license.

As someone who's built countless systems with these tools over the past decade, I have thoughts.
And some strong opinions.

## The Libraries We Love (And Sometimes Hate)

If you're a .NET developer, you likely use at least one of these:

[**AutoMapper**](https://github.com/AutoMapper/AutoMapper) (794.7M downloads) transforms objects from one type to another.
It removes mountains of tedious mapping code that nobody enjoys writing.
One line replaces twenty.
**I personally despise AutoMapper and mapping libraries in general**, but I can't deny their popularity.

[**MediatR**](https://github.com/jbogard/MediatR) (286.6M downloads) implements the [**mediator pattern**](cqrs-pattern-with-mediatr).
It decouples requests from the objects handling them, promoting separation of concerns.
There's also the pipeline behavior feature, which allows you to add cross-cutting concerns.
I'm a huge fan and use it regularly in my projects.

[**MassTransit**](https://github.com/MassTransit/MassTransit) (130.0M downloads) makes distributed messaging simple.
It wraps message brokers like [**RabbitMQ and Azure Service Bus**](using-masstransit-with-rabbitmq-and-azure-service-bus) with an elegant API.
Building event-driven systems becomes approachable.
This is another tool I love and often recommend.

These libraries aren't just popular - they're transformative.
They've shaped how we build .NET applications.

## The Maintainer's Reality

Both announcements tell a similar story.

<figure className="figure-center">
  <div className="bordered">
    <Image
      src="blogs/mnw_136/mediatr_automapepr_announcement.png"
      width={1183}
      height={801}
      alt="AutoMapper and MediatR Going Commercial."
    />
  </div>
  <figcaption>
    Source: [AutoMapper and MediatR Going
    Commercial](https://www.jimmybogard.com/automapper-and-mediatr-going-commercial/)
  </figcaption>
</figure>

Jimmy Bogard (AutoMapper, MediatR) writes:

> You can see exactly where my contributions cratered and flat-lined. And that's just commits—issues, PRs, discussions, all my time dried up.

His OSS work was previously sponsored by his former employer.
When he went independent, that support vanished.
His focus shifted to his consulting business.

<figure className="figure-center">
  <div className="bordered">
    <Image
      src="blogs/mnw_136/masstransit_announcement.png"
      width={1093}
      height={594}
      alt="Announcing MassTransit v9."
    />
  </div>
  <figcaption>
    Source: [Announcing MassTransit
    v9](https://masstransit.io/introduction/v9-announcement)
  </figcaption>
</figure>

Similarly, MassTransit has grown from "a single assembly that supported MSMQ" in 2007 to over thirty NuGet packages.
Its success created demands that are impossible to meet through volunteer work alone:

- Full-time development resources
- Enterprise-grade support
- Long-term sustainability

Both maintainers face the same dilemma: how do you support widely used libraries when nobody pays you to do it?

## The Commercial Transition

Here's what's happening:

**AutoMapper and MediatR**: Jimmy hasn't shared specific timing or pricing yet.
He states, "Short term, nothing will change."

**MassTransit**: Moving from v8 (open source) to v9 (commercial) with this timeline:

- Q3 2025: v9 prerelease for early adopters
- Q1 2026: v9 official release under commercial license
- Through 2026: v8 security patches continue

MassTransit's pricing targets:

- Small/medium businesses: $400/month or $4000/year
- Large enterprises: $1200/month or $12000/year
- Support for ISVs and consultants who build client applications

None of this is set in stone.
The pricing aspect should be final by the time the commercial version is released.

## Why I Respect This Decision

Both maintainers waited over a decade before making this move.
They've contributed immense value to our community for free.

Their announcements show careful consideration.
They're not abandoning users:

- Existing versions remain open source
- Security patches will continue
- Commercial licenses support sustainable development

I honestly hope none of the above changes in the future.
The work they do is valuable.

Writing these libraries from scratch would cost your team far more than their license fees.

## Your Options Now (With My Take)

If your project uses these libraries, you have choices:

1. **Purchase the commercial license**  
   This supports continued development and gets you new features and official support.

2. **Stay on the current open source version**  
   MassTransit v8 and current MediatR/AutoMapper will remain available.
   Security patches will continue through 2026 for MassTransit.
   For MassTransit specifically, I'd consider staying on v8 for the long term if possible.

3. **Switch to alternatives**  
   For AutoMapper: consider [Mapster](https://github.com/MapsterMapper/Mapster) or **manual mapping** (my recommendation).

   For MediatR: explore [FastEndpoints](https://github.com/FastEndpoints/FastEndpoints) or [**build a simple mediator yourself**](stop-conflating-cqrs-and-mediatr).

   For MassTransit: look at raw client libraries like [RabbitMQ.Client](https://www.nuget.org/packages/rabbitmq.client/) and
   [Azure.Messaging.ServiceBus](https://www.nuget.org/packages/Azure.Messaging.ServiceBus),
   and another option to consider is [**Rebus**](implementing-the-saga-pattern-with-rebus-and-rabbitmq).

4. **Write equivalent functionality yourself**  
   MediatR isn't too complex to build on your own.
   I recommend giving it a try as an excellent coding exercise - it's probably the simplest way to move away from MediatR.

   For AutoMapper, many teams have deep integrations with business logic in custom mappers.
   This makes extracting and replacing it difficult.
   Expect significant tech debt if you don't address this.

   MassTransit, on the other hand, does so many things (and does them well) that migrating away would be challenging.
   [**Saga support**](implementing-the-saga-pattern-with-masstransit) or the [**request-response messaging**](request-response-messaging-pattern-with-masstransit)
   features are hard to replicate.
   The only real alternative is diving into raw client libraries for your chosen message transport.

Each option involves tradeoffs. The right choice depends on your project needs and budget.

## A Shift to Fundamentals

These changes have made me reflect on something important: we should never lose sight of fundamentals.

We've been pampered and spoiled by these awesome libraries.
It's easy to lose sight of the actual problems they're solving and how they work under the hood.
People know how to use MediatR, but they don't understand the mechanisms behind it.

The same goes for MassTransit.
It abstracts away so many complexities of working with message brokers that it's possible to use it without knowing how RabbitMQ or Azure Service Bus actually works.

Remember this: using a library that abstracts something away doesn't excuse you from understanding the patterns and tools you're using.
The **fundamentals are still there** and always have been.
This might be the perfect opportunity to deepen your knowledge of what's happening beneath these abstractions.

## A Reality Check

Open source isn't free. Someone pays - either with time or money.

I'm honestly tired of seeing developers complain about these changes.
Who are they to demand software for free?
The entitlement is astounding.
These maintainers have provided immense value for over a decade without asking for anything in return.

We've enjoyed years of exceptional tooling without directly funding it.
Now we face a reckoning.

As businesses reap massive productivity gains from these libraries, it's reasonable to ask: shouldn't some of that value flow back to the creators?

I hope these projects thrive under their new models.
They've earned support after years of thankless work.

Both my [**Pragmatic Clean Architecture**](/pragmatic-clean-architecture) and
[**Modular Monolith Architecture**](/modular-monolith-architecture) courses currently use MediatR and MassTransit extensively.
I plan to keep them on MediatR v12 and MassTransit v8 in the short term.
However, I'll also be updating them to show migration paths away from these libraries.

What's your take?
Will you stick with the open versions, pay for licenses, or explore alternatives?

Thanks for reading.

And stay awesome!

---


Latest On YouTube

Let's connect

The .NET Weekly

Latest On YouTube

Let's connect