Bits of .NET

Why modern .NET 9 systems are moving away from rigid layers and embracing the “Vertical Slice” revolution.

For the past decade, Clean Architecture (or Onion Architecture) has been the gold standard for .NET developers. We’ve been told to separate our concerns into layers: Domain, Application, Infrastructure, and Web.

But as projects grow, we often find ourselves jumping through five different projects and ten folders just to add a single column to a Users table. We call it “decoupling,” but in reality, we’ve created unnecessary cognitive load.

The Problem: The “Abstractions” Trap

In a traditional Clean Architecture setup, a simple “Register User” feature is scattered across the solution:

• UserController in the Web Layer
• IUserService interface in the Domain Layer
• UserService implementation in the Application Layer
• IUserRepository interface in the Domain Layer
• UserRepository in the Infrastructure Layer

When you change a business rule, you end up modifying 4 or 5 projects. This is High Coupling disguised as Low Coupling.

The “Spaghetti of Abstractions”

Clean Architecture promises that your business logic will be independent of the database. “You can swap SQL Server for MongoDB in 5 minutes!” they say.

Question: In the last 10 years of your career, how many times did you actually swap your production database?

Probably never. Yet, we spend months building Generic Repositories and Unit of Work patterns to support a scenario that will never happen. This is Speculative Generality. In Vertical Slices, we embrace the tool. We use Entity Framework directly in our handler if it’s the most efficient way.

---

Enter: Vertical Slice Architecture

Instead of organizing code by Technical Type, we organize it by Features. Each slice is a standalone unit of work.

// Features/Users/RegisterUser.cs
public record Command(string Email, string Password) : IRequest<Result>;

public class Handler : IRequestHandler<Command, Result>
{
    private readonly AppDbContext _context;
    public Handler(AppDbContext context) => _context = context;

    public async Task<Result> Handle(Command request, CancellationToken ct)
    {
        // Everything for this feature lives HERE. 
        // Validation, Mapping, Database Logic.
        var user = new User { Email = request.Email };
        _context.Users.Add(user);
        await _context.SaveChangesAsync(ct);
        return Result.Success();
    }
}

Clean Architecture vs. Vertical Slice

Metric	Clean Architecture	Vertical Slice
Organization	By Layers (Horizontal)	By Features (Vertical)
Change Impact	Spreads across projects	Localized to one file
Boilerplate	High (Interfaces everywhere)	Low (Pragmatic)

The “Aha!” Moment: Lower Cognitive Load

The real win isn’t just “fewer projects.” When a bug is reported in “Order Processing,” a developer opens one folder. Everything—from the request shape to the database logic—is there. No more hunting through the “Infrastructure” project to find a shared repository.

Finding the Sweet Spot: Pragmatic Architecture

Don’t get me wrong: Clean Architecture is not “bad.” For massive enterprise systems with hundreds of developers, its strict boundaries provide a common language.

The problem is the “Golden Hammer” syndrome. We apply the same complex 5-layer template to a simple microservice. That is where Clean Architecture becomes “Dirty Over-engineering.”

Build Features, Not Layers.