Clean Architecture is about to change forever (and nobody even realizes)

You see it everywhere.

Most Clean Architecture diagrams follow the same structure, picturing 4 main circles:

• Entities
• Use Cases
• Controllers/Presenters
• Web/DB/UI

And translating that to the .NET projects:

• Domain
• Application
• Infrastructure
• WebApi

The only problem?

That mindset is stuck in 2012. With the evolution of the .NET ecosystem, the Clean Architecture has to change as well. And evolve into a leaner architectural style.

Here are 3 .NET trends that will change Clean Architecture forever.

1. Rise of Vertical Slice Architecture (VSA)

The vertical slice architecture, where you group related classes by features, rather than by technical concerns, is becoming increasingly popular.

And it makes sense.

It’s 100 times easier to have a folder where you group all feature-related classes:

• Request
• Response
• Use Case Handler
• Some helper class (which you obviously shouldn’t name Helper, lol)

Than to have folders like:

• Interfaces
• Validators
• Services
• Helpers
• Requests
• Responses

And each of them contains 100 unrelated items grouped by their technical concern.

If you take a closer look at one of the most popular Clean Architecture repos, the one from Steve Smith (Ardalis), you’ll see the same grouping by features:

Benefits are:

• You don’t have to jump around the solution while implementing the feature. Everything is in a single place.
• You reduce the risk of breaking unrelated features because the code is separated by slices.
• Onboarding new developers becomes dramatically faster. They can learn one feature end-to-end without having to understand the entire system’s structure.

Humans are lazy creatures.

Our monkey brain naturally gravitates toward what’s easier, to preserve energy and mental capacity.

And VSA is one of those brain energy savers.

2. Minimal API

When Microsoft introduced Minimal APIs in .NET 6, they felt… well, minimal.

Incomplete.

A quick way to create a prototype app.

Fast forward to .NET 10, they’ve grown into a serious option for building production APIs while keeping Clean Architecture principles intact.

You can:

• Easily inject dependencies
• Adopt vertical slice patterns effortlessly
• Reduce boilerplate compared to full-blown controllers

Yes, there are still some feature gaps compared to controllers, as explained at the end of this page.

But given that .NET 10 has improved validation in minimal APIs…

…and that .NET 9 already increased its performance:

• 15% increase in RPS (Requests per Second)
• 93% decrease in memory usage

Minimal APIs have become a viable option for building production apps.

3. Gravitating toward solution simplicity

Another trend:

Many .NET projects are dropping the “Domain” layer as a physical project, at least initially.

Ok, “dropping” is a bit too harsh.

But instead, Application and Domain layers blend into a single project: Core.

Heck, even Microsoft does this.

Why does this happen?

Because many projects have a natural evolution:

• Start simple, a lot of CRUD code. Ship fast.
• As the time goes on, the users want more features. The app gets more code and thus more logic.
• Then you extract the Domain into a separate project if needed.

Domain and application logic can live in the same assembly without losing clarity. Especially in smaller to medium-sized systems.

Less ceremony, fewer projects to navigate, and fewer assemblies to maintain and upgrade.

That’s why I often start with the 3-project CIA Blueprint solution structure.

I explain the CIA Blueprint (with complete source code) in the Zero to Architect Playbook course (module 2, lesson 9), but .NET solution starting with Core, Infrastructure, and API projects enables things to stay simple. Yet, it separates nicely the domain (located in Core) from external dependencies (located in Infrastructure) and Web functionality (located in the Api project).

Clean Architecture isn’t dead.

But the old playbook is.

If you’re still structuring .NET projects like it’s 2012, you’re leaving maintainability, speed, and sanity on the table.

In 2026, architecture isn’t about sticking to a diagram.

It’s about making the right trade-offs for your project, your team, and your future self.