The .NET Architecture Pattern That Looks Professional but Scales Like Trash (and What to Do Instead)

The .NET Architecture Pattern That Looks Professional but Scales Like Trash (and What to Do Instead)

TL;DR — The “enterprise-clean” layering stack (Controller → Application Service → Use Case/Handler → Port → Adapter → Repository → ORM) wins design reviews because it looks disciplined. At scale, it quietly taxes throughput: deep call stacks, excessive allocations, container‑resolved object graphs, ORM leakage hidden behind interfaces, async theater, and cross‑cutting decorators multiplying per‑request work.


The fix is not “no architecture.” The fix is: make costs visible, keep hot paths honest, and introduce abstractions only where change/volatility is real.

This is written for systems that already crossed the “it works” phase and entered the part that matters: SLOs, p99 latency, GC pressure, query plans, and cloud cost.

The pattern that gets applause (and then invoices)

Here’s the “looks professional” request path most .NET teams ship when they want to look serious:

// Controller

public async Task<IActionResult> GetOrder(Guid id)

    => Ok(await _getOrderUseCase.ExecuteAsync(id));

// Use case

public async Task<OrderDto> ExecuteAsync(Guid id)

{

    var order = await _orderRepository.GetByIdAsync(id);

    return _mapper.Map<OrderDto>(order);

}

// Repository

public Task<Order?> GetByIdAsync(Guid id)

    => _db.Orders

        .Include(o => o.Items)

        .FirstOrDefaultAsync(o => o.Id == id);

On paper: clean boundaries, test seams, separation of concerns.


In production: you’ve created a system where costs are hidden by design.

At scale, bottlenecks rarely announce themselves as “architecture.” They show up as:

• p95/p99 latency drift that “doesn’t correlate to CPU” until it does.


• Gen0/Gen1 GC rising with traffic even when business logic is simple.


• “EF Core is slow” becoming the scapegoat for a pipeline of allocations and indirection.


• Debugging a missing index requiring a tour through five interfaces and two mappers.

The architecture didn’t fail because someone implemented it wrong.


It failed because it optimized for professional aesthetics instead of runtime reality.

1) Abstraction inflation: forwarding chains that pay rent per request

A common hallmark: multiple types exist to forward one call.

public interface IOrderService

{

    Task<OrderResult> GetOrderAsync(Guid id);

}



public sealed class OrderService : IOrderService

{

    private readonly IOrderUseCase _useCase;

    public Task<OrderResult> GetOrderAsync(Guid id) => _useCase.HandleAsync(id);

}



public interface IOrderUseCase

{

    Task<OrderResult> HandleAsync(Guid id);

}

Three types. One behavior. Zero additional business meaning.

At 5 requests/second? Nobody cares.


At 5,000 requests/second? You are paying for:

• method call indirection


• object graph resolution


• allocations (often accidental: closures, iterators, mapping, async state machines)


• deeper stacks (harder profiling, harder inlining, harder to see hot paths)

The cost isn’t one layer. The cost is multiplication across a codebase with dozens of “just in case” abstractions.

Scalable systems don’t avoid abstraction. They avoid unearned abstraction.

2) “Clean” repositories that hide the real problem: query shape

Repositories often push teams toward entity-returning APIs that look pure but are operationally blunt instruments.

public Task<Order?> GetByIdAsync(Guid id)

    => _db.Orders

        .Include(o => o.Items)

        .ThenInclude(i => i.Product)

        .FirstOrDefaultAsync(o => o.Id == id);

This is how you accidentally ship:

• wide joins


• large graphs for small responses


• tracking when you don’t need it


• serialization bloat


• N+1 when navigation usage escapes into other layers

Then you “fix performance” by adding caching or more instances—because the architecture hides the query cost until it’s a fire.

Reads at scale are shaped for usage, not purity. The correct model for reads is often not your domain entity.

3) ORM leakage: DbContext behavior bleeds through the boundary anyway

The architecture claims “infrastructure is isolated,” but EF behavior leaks:

public sealed class Order

{

    public ICollection<OrderItem> Items { get; set; } = new List<OrderItem>();

}



// Somewhere later:

var total = order.Items.Sum(i => i.Price);

If Items is not loaded the way you think, you get:

• N+1


• big object graphs


• lazy loading surprises


• accidental tracking


• query explosions

And because you buried EF behind an interface, you made it harder to reason about.

In production you don’t need a boundary that pretends EF isn’t there.


You need a boundary that makes the data shape explicit.

4) DI worship: when “testability” becomes a per-request allocation tax

DI is not the villain. Blind DI is.

services.AddScoped<IOrderService, OrderService>();

services.AddScoped<IOrderUseCase, OrderUseCase>();

services.AddScoped<IOrderRepository, OrderRepository>();

services.AddScoped<IMapper, Mapper>();

services.AddScoped<IValidator<OrderQuery>, OrderQueryValidator>();

// ...x50 more per feature

At high throughput, this pattern is expensive because of the total graph:

• constructor chains grow


• transients multiply


• GC runs more often


• cold start worsens


• container diagnostics become part of your performance story

Under load, you end up with a “clean” system where your hottest code path is:


resolve dependencies → forward calls → allocate DTOs → map objects → serialize.

Rule that scales: Use DI for volatility and cross-cutting services.


Do not DI‑wrap every tiny behavior “because architecture.”

If a class only forwards calls, it isn’t a seam. It’s a toll booth.

5) Async everywhere, throughput nowhere: async theater

Async is for I/O boundaries.


Async for CPU/in-memory work is overhead disguised as modernity.

public async Task<OrderSummary> CalculateAsync(Order order)

{

    return await Task.FromResult(new OrderSummary(order.Items.Sum(i => i.Price)));

}

You added:

• async state machine


• scheduling overhead


• cognitive noise


• no benefit

At scale, the overhead compounds across layers because now everything is Task<T> by default, even when the work is immediate.

Rule that scales: Make sync code sync. Make I/O async. Be honest.

6) Cross-cutting decorators that multiply work per request

“Clean” architectures often implement logging/metrics/retries as decorators:

public sealed class LoggingOrderUseCase : IOrderUseCase

{

    private readonly IOrderUseCase _inner;

    private readonly ILogger<LoggingOrderUseCase> _logger;



    public async Task<OrderResult> HandleAsync(Guid id)

    {

        _logger.LogInformation("Start {OrderId}", id);

        var result = await _inner.HandleAsync(id);

        _logger.LogInformation("End {OrderId}", id);

        return result;

    }

}

Add metrics, caching, retries, validation, auth—now your “simple request” hits 5–10 wrappers before the database.

This isn’t always wrong. It’s just rarely measured.


You’re stacking costs without owning the budget.

Rule that scales: Centralize cross-cutting concerns where possible (middleware / interceptors / OTel), and measure them.

What actually scales: boring, direct, honest design

The alternative isn’t “spaghetti.” It’s truthful composition:

• Make reads explicit.


• Keep write paths intentional.


• Introduce abstractions when change/duplication is proven.


• Treat performance as a first-class API constraint.

Here’s the “boring” version of GetOrder that scales better because it is explicit about shape and cost:

public sealed record OrderDto(Guid Id, decimal Total);



public async Task<IResult> GetOrder(Guid id, AppDbContext db, CancellationToken ct)

{

    var dto = await db.Orders

        .AsNoTracking()

        .Where(o => o.Id == id)

        .Select(o => new OrderDto(

            o.Id,

            o.Items.Sum(i => i.Price)))

        .FirstOrDefaultAsync(ct);



    return dto is null ? Results.NotFound() : Results.Ok(dto);

}

No repository. No mapper. No fake isolation.


Just a query shaped to the response.

This doesn’t forbid architecture. It forbids hiding the cost.

A pragmatic 2026 model: “thin architecture, thick measurement”

If your system has to scale, you don’t need more layers. You need better contracts.

Reads

• Use projection (Select) into DTOs.


• Prefer AsNoTracking() on read endpoints.


• Consider compiled queries for hot paths.


• Treat N+1 as a bug, not a style discussion.

Example: compiled query for a known hot endpoint:

public static class Queries

{

    public static readonly Func<AppDbContext, Guid, CancellationToken, Task<OrderDto?>>

        GetOrderDto =

            EF.CompileAsyncQuery((AppDbContext db, Guid id, CancellationToken ct) =>

                db.Orders.AsNoTracking()

                    .Where(o => o.Id == id)

                    .Select(o => new OrderDto(

                        o.Id,

                        o.Items.Sum(i => i.Price)))

                    .FirstOrDefault());

}

Usage:

var dto = await Queries.GetOrderDto(db, id, ct);

Writes

• Keep domain logic where it matters, but don’t force every write through 7 layers.


• Use explicit transaction boundaries where needed.


• Don’t hide EF tracking behind “repositories” that pretend it isn’t tracking.
  

public async Task<IResult> UpdateOrderStatus(

    Guid id,

    UpdateStatusRequest req,

    AppDbContext db,

    CancellationToken ct)

{

    var order = await db.Orders.FirstOrDefaultAsync(o => o.Id == id, ct);

    if (order is null) return Results.NotFound();



    order.Status = req.Status;

    order.UpdatedAtUtc = DateTime.UtcNow;



    await db.SaveChangesAsync(ct);

    return Results.NoContent();

}

Abstractions

Introduce them for volatility, not for vibes:

• multiple persistence models


• external systems that change (payments, providers)


• domain policies that evolve


• shared behavior that is actually shared
  

If you only have one implementation and it never changes, that interface is a costume.

The “seam” you actually want: feature boundaries, not forwarding layers

Instead of Controller → Service → UseCase → Repo, consider a feature folder boundary with explicit query/command handlers (but not ceremonial forwarding). Example layout:

/Features/Orders

  GetOrder.cs

  UpdateOrderStatus.cs

  OrdersEndpoints.cs

  OrdersMapping.cs (if needed)

GetOrder.cs holds the read model and query.


UpdateOrderStatus.cs holds the command logic.


EF usage is explicit, so cost stays visible.

This scales better organizationally too: a developer can open one folder and see the full behavior end-to-end.

“But what about testability?”

Testability that ignores production reality is theater.

The pattern usually gives you unit tests that mock the world:

_mockRepo.Setup(r => r.GetByIdAsync(It.IsAny<Guid>()))

    .ReturnsAsync(new Order());

This doesn’t test:

• query shape


• indexes


• serialization size


• tracking behavior


• N+1


• real latency paths

For scalable systems, prefer:

• 
  integration tests for data access (real DB in CI if possible)


• 
  contract tests for API responses


• 
  load tests for hot paths


• 
  profiling gates for regressions

You want tests that keep you honest, not tests that keep you comfortable.

How to refactor the “professional” pattern without blowing up the codebase

You don’t delete all layers in a weekend. You remove cost where it matters.

Step 1 — Identify hot paths

Start with evidence:

• p95/p99 endpoints


• top allocation sites


• slow SQL and query plans


• GC pressure under load

Tooling that pays back quickly:

• 
  dotnet-counters (GC, exceptions, threadpool)


• 
  dotnet-trace (CPU sampling)


• OpenTelemetry traces (request → DB timings)

Step 2 — Collapse read paths first

Reads dominate most systems. Replace “repository returns entity graph” with explicit projections for the top endpoints.

Step 3 — Reduce indirection where it adds no behavior

If a type only forwards a call, merge it.

Step 4 — Contain EF, don’t disguise it

Keep EF usage explicit in read/write handlers. If you need a boundary, make it a query boundary, not an entity-returning repository boundary.

Step 5 — Keep DI, but stop worshipping it

Compose the real dependencies. Do not register a class just because the pattern wants another layer.

The actual definition of “professional” in 2026

Professional architecture is not the number of folders named Domain.

Professional architecture is:

• predictable p99 latency,


• understandable runtime paths,


• cheap enough to run,


• safe enough to evolve,


• and honest enough to optimize.

If your architecture looks great in diagrams but becomes untraceable under load, it isn’t professional.


It’s decorative.

Final take

If your system feels “senior” on day one but fragile on year three, you’re not crazy.


You’ve probably shipped an architecture optimized for approval, not survival.

The uncomfortable question that saves systems is always the same:

Where does the cost show up — and can we see it without digging through five interfaces?

— Written by Cristian Sifuentes


Full‑stack engineer · .NET architect · performance‑first systems thinker