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 pub