When C# Code Smells: Choosing the Right Pattern Without Overengineering

You're staring at a C# codebase that's been patched six ways to Sunday. Deadlines loom, junior devs keep adding magic strings, and your tech lead just proposed a full rewrite with 'event sourcing and CQRS.' Classic.

But here's the thing: most C# teams don't fail because they picked the wrong pattern. They fail because they never decided—they just coded. This article gives you a framework to pick intentionally, avoid the traps, and ship maintainable code without burning out. No silver bullets, just trade-offs.

Who Should Decide and When?

Who actually owns this call?

The person who reaches for a pattern — the one who says 'we need a hexagonal architecture here' — should not be a junior who just finished a Clean Architecture YouTube series. I have seen that movie. It ends with six empty projects, three unused interfaces, and a two-week delay on a feature that should have taken two days. The decision maker is the lead dev or the architect, full stop. Why? Because they carry the context: they know which parts of the system will hurt in six months, which seams are already cracking, and which pattern will actually save time rather than burn it. A solo dev can also own this — but only if they force themselves to think like an architect for thirty minutes before writing any code. That means stepping away from the keyboard. Literally. Draw boxes on paper, then write.

Decision timing: before sprint 1 or during refactor?

Most teams get this backwards. They pick a pattern in the first week of a greenfield project, before they understand the domain, and then spend three months fighting the abstraction. The catch is — not deciding early can be just as toxic. I have watched teams build one thousand lines of tightly coupled logic in a console app, then try to retrofit a mediator pattern. That refactor took longer than the original feature. The sweet spot? Decide after sprint 2 or 3, when you have real user feedback and a sense of which boundaries keep shifting. If the team has fewer than five devs, wait even longer — the overhead of layers will outrun the complexity they contain. Wrong order kills velocity. Right timing saves it.

Signals that force a decision now

A few concrete symptoms: test setup takes longer than writing the actual logic. Or you can't run the application without spinning up a database, Redis, and an email server — because everything is coupled to everything. Another sign: you're on your third rewrite of the same business rule because it lives in a controller, then a service, then a helper class that nobody owns. That hurts. When these appear, you stop debating and pick a pattern — not the fanciest one, the one that isolates the pain. 'But what if we pick wrong?' someone will ask. Fine. Pick something minimal. Refactor later. The real cost is indecision, not imperfection.

'Most teams spend more time choosing the perfect architecture than they do shipping the feature that would tell them what architecture they actually need.'

— overheard at a C# meetup, paraphrased from a lead who had been burned three times

One more thing: if you're a solo dev, you get to skip the meeting overhead. That's an advantage. Use it. Decide fast, build ugly, refactor when the pain is real — not when some blog post tells you to.

The Options: From Straightforward to Fancy

Layered Architecture

The classic onion — presentation, business logic, data access — stacked vertically. It’s the first pattern most of us learned, and for good reason: you can explain it on a napkin. We fixed a client’s inventory system with this in two days because the team already spoke that language. No ceremony, no adapters for imaginary ports. The catch? That neat layering decays fast. I have seen a “clean” three-layer app where the UI project referenced the DAL directly — shortcuts everywhere. When your business logic leaks into controllers or your repository returns IQueryable, the layers become fiction. What usually breaks first is testability: mocking a concrete DbContext across layers hurts, and suddenly your unit tests are integration tests. It’s simple, it’s cheap, and it works — until you need to swap databases or your validation rules span five tables.

‘Layers are like fences: they keep things in order, but a determined team will jump right over them.’

— senior dev after untangling a six-year-old monolith, personal conversation

Clean / Hexagonal Architecture

Ports and adapters. Domain at the center, infrastructure at the edges. Sounds noble — the database becomes a plugin. But I’ve witnessed teams spend three sprints drawing dependency arrows and zero sprints writing actual features. The pro: your core logic stays pure, untouchable by SQL or HTTP. The con: you introduce interfaces for things that may never change. That IEmailSender interface with one implementation? It’s ceremony tax. The pitfall is over-abstraction. Most teams skip the step where they ask: “Do we have two use cases that genuinely need different adapters?” If the answer is no, hexagonal is premature. Where it shines is when you do have two delivery mechanisms — an API and a batch job consuming the same core — or when your boss demands a database swap next quarter. Otherwise you’re building a spaceship to cross the street.

CQRS + Event Sourcing

Separate commands from queries. Store events, not current state. It’s the fancy option — and it smells like overengineering until it isn’t. The honest pro: audit trails are free; you can rebuild any past state on demand. We used this for a financial ledger where “show me what happened on Tuesday” was a legal requirement. The con? Read models lag, eventual consistency bites you, and debugging a chain of replayed events is miserable. That rhetorical question — “do you really need to know why an order was canceled three months ago?” — answers itself for most apps. If your domain has strong temporal rules (booking slots, inventory reservations, compliance logs), event sourcing earns its complexity. If it’s a blog CMS, you’re just burning RAM.

Reality check: name the development owner or stop.

Functional C# with language-ext

Stick with me — this isn’t academic. Language-ext brings monads like Option<T> and Either<L, R> into your project. The payoff: null disappears, exceptions become explicit types, and your method signatures tell the truth. “But we’re C# devs!” I hear that. The trade-off is steep: your team must unlearn years of imperative habits. A junior writing if (result.IsNone) return NotFound() is fine. The same junior chaining five Bind calls inside a LINQ query? That’s a code review nightmare. What usually breaks first is interop — calling a third-party library that throws NullReferenceException kills the purity. Honestly, I’d only reach for this on greenfield projects with a team that already reads Haskell for fun. For everyone else: steal just the Option type and stop. Baby steps beat a broken pipeline every time.

How to Compare: Criteria That Actually Matter

Team Size and Skill Distribution

I once watched a four-person team adopt a full event-sourcing architecture because one senior dev read a blog post. The result? Three juniors spent two months fighting serialization bugs while the senior was at a conference. That matters. Your team's size and skill distribution aren't abstract HR metrics—they're the single biggest constraint on pattern choice. A layered architecture works when you have two mid-level devs and one junior who needs guardrails. Hexagonal or CQRS demands at least two people who have debugged it in production before. The tricky bit is honesty: most teams overestimate their own capability. Ask yourself: can every team member explain the pattern's failure modes in five minutes during an incident? If not, you've already picked a risk, not a solution.

Expected Project Lifespan

A CRUD dashboard that replaces itself in eighteen months doesn't need clean architecture. I have seen teams spend three sprints abstracting a database they swapped exactly zero times. That hurts. For short-lived projects (under two years), straight N-tier or simple MediatR pipelines are fine—you'll throw the code away anyway. For projects with a five-to-ten year horizon, you need something that survives staff turnover, library deprecation, and the inevitable "we now support mobile, too" meeting. The catch is that longevity alone doesn't justify complexity. A ten-year internal tool with three users still benefits from simplicity. The deciding factor is how many directions the system must stretch over its life, not just how long it lives.

Change Frequency and Domain Complexity

Most teams skip this: counting how often a single bounded context actually changes. Pick one module—say, order processing. Does it get modified monthly, quarterly, or once a year? High change frequency combined with tangled domain rules (discounts overlapping with shipping zones, complex state machines) is where patterns earn their keep. That's when you want ports and adapters, or domain events, because the seams let you replace pieces without blowing up the whole thing. Low-change domains (user authentication, audit logging) don't need those seams—they need to stay out of the way. The pitfall is applying the same pattern to both. I've debugged a hexagonal auth module that had six interfaces for password hashing. Nobody needed that.

'Every abstraction is a bet against future change. The question isn't whether you'll need it—it's how much you'll lose if the bet is wrong.'

— Staff engineer, during a post-mortem I sat in on, 2023

Operational Cost: Deploy, Debug, Onboard

Fancy patterns don't stay in the codebase—they leak into deploy pipelines, logging, and onboarding. One team I advised used a saga orchestration pattern for a three-step workflow. Deployment went from a single click to a thirteen-step runbook with failure recovery procedures. Debugging required opening five microservice logs simultaneously. New hires took three weeks to ship their first change. That's operational debt, and it compounds faster than any code debt. Compare: how many steps does a new developer need to trace a request through your system end-to-end? If the answer involves 'open the event store' or 'check the outbox table,' you've added cost. The trick is to weigh that cost against real, measured pain—not hypothetical future scalability. If your deploy pipeline is already painful, don't add pattern complexity to it. Simplify the pipeline first, then consider the architecture. Wrong order kills projects.

Trade-Offs at a Glance: When Layers Beat Hexagons

Performance vs. testability — the axis nobody wants to compromise

Clean hexagonal architectures promise isolation—your domain logic sits behind ports and adapters, free from database drivers or HTTP concerns. That sounds fine until your first latency spike hits production and suddenly every mock-friendly abstraction layer adds 0.2ms per call. I have seen teams chase perfect testability only to ship code that buckles under 500 requests per second. The catch? A three-layer vertical slice—repository, service, controller—runs circles around a full onion ring setup when every millisecond matters. Most teams skip this trade-off entirely, assuming they can "optimize later." They can't—not when the abstraction boundaries require rewriting half the adapter stack to inline a hot path.

But here's the asymmetry: you can always add test seams later if your code follows consistent dependency injection patterns. Starting with raw performance and retrofitting testability? That hurts. The real question isn't which approach is better—it's whether the extra 3ms matter more than the 30 minutes of mocking you'll do per test suite. Wrong order, and your CI pipeline becomes a prayer.

Speed of delivery vs. long-term flexibility — the trap of "just ship it"

"We'll refactor when we need to. Right now we need to move fast."

— every team lead three months before a monolithic rewrite, circa 2023

That impulse is understandable—deadlines are real, and a five-layer factory pattern for a two-entity CRUD endpoint is architectural cosplay. I have fixed exactly that mistake: a junior dev told to "follow the architecture" ended up with 15 files for a user login. However, the opposite disaster is subtler: you skip the pattern choice entirely, write everything in the controller, and six months later the business logic is tangled across four request handlers. What usually breaks first is not the architecture—it's the developer's ability to reason about a single change without breaking three unrelated features.

Fast delivery with zero pattern choice gives you velocity for exactly two sprints. After that, each feature takes longer because there is no natural seam to insert new behavior. The trick is to recognize when your speed-to-flexibility graph flips—typically around the third time you copy-paste the same validation logic across handlers. That's the moment to stop and pick one structural approach, even if it feels like overkill today.

Developer happiness vs. hiring pool — the real hidden cost

Hexagonal architecture excites engineers who love domain-driven design and hexagonal conference talks. It also confuses the hell out of developers who learned CRUD on a simple three-tier stack. You might build a beautiful, pattern-perfect solution—then watch your new hire struggle for two weeks to trace a single request through six abstraction layers. I have seen a five-person team burn 40% of a sprint explaining "why the repository interface lives in a different project." That's a cost.

Odd bit about development: the dull step fails first.

The pragmatic middle? Use layers where the team's skill level matches the complexity. A straight vertical-slice-with-interfaces approach often wins: it keeps the mental model flat enough for new joiners but leaves the door open for hexagonal refactoring in the hot spots. Developer happiness doesn't come from purity of architecture—it comes from being able to ship a fix on Friday without waking the on-call engineer. Your hiring pool will thank you later, and honestly—your future self will too when you don't have to explain abstraction inversion in a code review at 4 PM on a Friday.

After You Choose: Implementation Steps That Stick

Start with a vertical slice — not a horizontal layer

The fastest way to kill a pattern decision is to build it in theory. I’ve seen teams spend two weeks crafting a perfect onion architecture — only to discover their actual data flow needs a different seam entirely. So: pick one end-to-end user story — one — and implement it all the way through. Database table, repository, service, controller, maybe a background worker if that’s the story. That single slice exposes every mismatch between your chosen pattern and real I/O. You’ll spot the awkward abstraction, the over-split interface, the repository that returns IQueryable when the client needs a flat DTO. Fix those before you touch a second feature. If the slice works, commit the structure. If it fights you, pivot — you’ve lost a day, not a quarter.

Setting up dependency injection properly — or paying later

Most teams get DI wrong not at registration time, but at composition-root time. The catch is that ASP.NET Core’s built-in container makes it dangerously easy to register everything in Program.cs with a single AddScoped loop. Don’t. Instead, create an ApplicationServiceRegistration extension method per project — one for your domain services, one for infrastructure. Each method lives in its owning assembly. That way, when the OrderProcessingModule suddenly needs a new IInvoiceGateway, you add it to the infrastructure extension, not the web project. We fixed a production incident last year by tracing a transient-disposed bug to a mis-registered IEmailSender — wrong lifetime, wrong assembly. That hurt. A concrete step: use Scrutor to scan and register open generics (IHandler<,>), but always override specific registrations in the owning extension. Leave a comment explaining why the override exists — otherwise someone will undo it in two months.

The tricky bit is lifetime conflicts. A scoped DbContext injected into a singleton? That blows up at runtime. Most teams skip this: write a startup test that resolves every registration and checks lifetime compatibility. We put ours in the integration test project; it runs in CI. Catches about three mismatches per sprint.

Enforcing conventions with analyzers — catch the drift early

You chose the pattern. Now one developer names a repository IOrdersRepo, another calls it OrderDataAccess, and a third slaps public on an internal helper. Conventions erode fast. Instead of policing pull requests, write a Roslyn analyzer — or, honestly, start with a .editorconfig and custom rule set. Enforce namespace conventions (all domain interfaces under .Abstractions), ban new() calls outside composition root, flag circular project references. One rule that saved us: analyzer prohibits injecting IServiceProvider anywhere except the composition root. That single check halved our service-locator incidents. What usually breaks first is the analyzer itself — team members ignore squiggly lines. So configure the severity to error, not warning. Block the build. Pain drives discipline.

Documenting decisions, not code

Comments that explain what a method does rot. But a short decision record — “We chose a mediator pattern here because the orchestration logic was duplicated across three controllers, and adding a fourth would require touching all three” — that stays valuable. We keep these as markdown files inside the solution, one per bounded context. Name each one DECISION-{date}-{topic}.md. Write three sentences: context, decision, consequence. No more. I’ve seen teams waste hours reverse-engineering why a hexagonal boundary was pulled two layers up. A four-line document would have saved that. You don’t need Arc42; you need a note that says “We broke the IReporting interface into two because the export path and the analytics path had zero overlapping implementations.”

“Document the why, not the what. The code already tells you what. The code never tells you why.”

— overheard at a .NET meetup, after someone’s third refactor of the same module

Risks: What Happens When You Pick Wrong or Skip Steps

Premature abstraction hell

You extract an interface for every class on day one. Just in case you swap out the logger, the repository, the email sender. Then you never swap them. Six months later you have 47 interfaces with exactly one implementation each. I watched a team do this—spent two sprints building an abstraction layer that handled three different database providers. They were using SQL Server. The whole time. That abstraction? It didn't catch a single bug, didn't enable a single feature swap. What it did do: triple the indirection in every stack trace and make junior devs afraid to touch anything. The catch is that abstractions cost you now—cognitive load, navigation time, test setup complexity. You need to ask yourself: does this interface pay rent today, or am I just decorating the code?

Over-engineering for 'future-proofing'

Someone on the team reads about hexagonal architecture and decides the CRUD endpoint needs ports, adapters, domain events, and a CQRS split. For a form that saves a user's name. That hurts. The system hasn't shipped yet, but now you're maintaining six projects in a solution that moves three columns around. The real risk isn't wasted typing—it's that you burn team momentum before you have feedback from actual users. Most future-proofing guesses are wrong. The feature that comes next is never the one you padded for. I've seen teams deliver a perfect onion-layered monolith only to discover the business needs a completely different data model six weeks later. Now they have to peel every layer. Not fun.

Honestly—the most dangerous pattern choice is the one that fits your resume's buzzword count better than your problem's actual shape.

Ignoring team skill gaps

You pick event sourcing because it's elegant. Your team has never used it. Nobody on the team has built a projection before. Three weeks in, disaster recovery fails silently because nobody understood the snapshotting semantics. The code compiles. Tests pass. But in production the event store grows unbounded and your read models desync without warning. What usually breaks first is not the pattern itself—it's the debugging skills nobody had time to develop. If the team can't reason about the mental model, they'll patch around it with hacks. Those hacks become the real architecture.

Not every development checklist earns its ink.

'We adopted the mediator pattern across all handlers. Two months later nobody could follow a request through the pipeline.'

— Lead dev, post-mortem on a C# monolith rewrite

Not revisiting the decision

You chose a repository pattern in month one. Fine. Month eight rolls around and you're doing complex aggregations—your ORM already handles those natively, but the repo abstraction forces you to load entire entity graphs into memory and filter in-memory. Nobody questions it because "that's the pattern we decided on." Wrong order. Patterns need expiration dates. If you never revisit the choice, you're cargo-culting your own past. A good rule: when a pattern adds more friction to change than it removes, you're paying a tax for no benefit. Drop it. Replace it with direct calls. Refactor the surface. Nobody will award you a medal for consistency when the page renders in 12 seconds.

Mini-FAQ: Quick Answers to Common Doubts

Do I really need DI containers?

Not always — and that answer surprises a lot of C# developers. If you're writing a console utility, a tiny background service, or a prototype that'll live a week, injecting via constructor manually is fine. I have fixed production bugs caused by AutoFac registrations that were harder to trace than the missing interface they were meant to solve. The trade-off hits when your object graph exceeds maybe six manual dependencies. At that point the wiring turns into a chore, registration errors creep in, and you lose a day to a null reference you could've caught at compile time. That's when a container becomes a tool, not a fashion statement.

The catch is that people wire up DI containers before they have three classes. That hurts. You end up refactoring registration code almost as much as business logic. Start with manual construction. Add a container when you genuinely feel the friction — not because "everyone does it." Most teams skip this step and pay for it in configuration bloat.

“A DI container is a solution to a coordination problem you haven’t yet created. Don’t import it as insurance — import it as a pain reliever.”

— paraphrased from a code review I left after untangling someone's third unnecessary lifetime scope

When should I use records vs. classes?

The short rule: records for dumb data, classes for behavior that remembers. I have seen teams turn every little DTO into a full class with equality overrides and IEquatable implementations — that's wasted keystrokes. A record gives you value equality, immutability by default, and a cleaner ToString(). Use it for API responses, event payloads, configuration snapshots. But records start to smell when you add mutable state or inheritance hierarchies. That's when you want a plain class.

Honestly — the boundary blurs with positional records that have methods. That's fine until you try to deserialize a record with a parameterized constructor that also needs init-only properties. Then you're debugging JSON serialization instead of shipping features. Stay conservative: records for transfer objects, classes for domain models that change over time. Wrong order? You'll feel it when a single record field suddenly needs lazy loading or a side effect.

Is functional C# production-ready?

Yes — but only in the places where it buys you clarity. We fixed a gnarly order-processing pipeline by replacing a switch statement with pattern matching and immutable result types. It halved the bug count. That said, forcing monads everywhere without a team that understands them is a recipe for confusion. You'll see Either<TLeft, TRight> wrappers that nobody wants to touch because the error channel is undocumented. Functional patterns work beautifully for data transformation chains, concurrency flows, and parsing logic. They fall apart in HTTP-heavy business logic where side effects are the point.

What usually breaks first is exception handling. A Result type that wraps every possible failure mode looks elegant until you need to log context from three layers up. Then you either swallow information or bolt on callbacks that defeat the purpose. Start with one method — a TryParse replacement, a validation chain — and see if your team's review comments shift from "what does this do" to "that's cleaner." If they don't, the abstraction is costing you.

How much test coverage is enough?

The number that kills projects is 100% — because nobody achieves it honestly. I have seen teams with 80% branch coverage and zero confidence in their deployment because the tests only exercised paths the developer already knew worked. The real floor is the code that hurts when it breaks. Core calculations. Serialization edges. Payment or permission logic. Cover those with coarse integration tests first, then unit tests for the weird branches. The rest?

Not yet. You'll discover where coverage is thin the instant staging returns a 500 on a field you forgot to validate. That pain points exactly at the next test to write. Chasing a coverage percentage without that feedback loop produces tests that pass but prove nothing. One concrete rule: if a method has a conditional in production that no test exercises, you're gambling. Fix that one first. Then measure.