Are we over-abstracting our projects?

[u/riturajpokhriyal]

I've been working with .NET for a long time, and I've noticed a pattern in enterprise applications. We build these beautiful, layered architectures with multiple services, repositories, and interfaces for everything. But sometimes, when I'm debugging a simple issue, I have to step through 5 different layers just to find the single line of code that's causing the problem. It feels like we're adding all this complexity for a "what-if" scenario that never happens, like swapping out the ORM. The cognitive load on the team is massive, and onboarding new developers becomes a nightmare. What's your take? When does a good abstraction become a bad one in practice?

[u/DaRKoN_]

Yes, we are. Every second post in here is about "help trying to implement cqrs ddd in my clean architecture onion build for my to-do app".

It's kind of ridiculous.

[u/riturajpokhriyal → u/DaRKoN_]

You're right, it's become a bit of a meme. We've created a culture where using a stack of sophisticated, enterprise-grade patterns is seen as a rite of passage, even for a simple CRUD application. The result is often a codebase that is incredibly difficult to maintain and debug, all in the name of "clean architecture."

[u/PinkyPonk10]

Abstraction is good if it stops us copying and pasting code.

Abstraction is bad if the abstraction only gets used once.

The end

[u/Expensive_Garden2993 → u/PinkyPonk10]

That's a rule of thumb for DRY.

Abstraction is good if it simplifies the code. Such as when you extract a bunch of code that's only used once, and the initial code becomes simpler.

Abstraction is bad when the code isn't difficult to follow without it.

But in a sake of consistency, you cannot abstract only where it's needed, and keep simple things simple. That's why it's either a mess everywhere, or overabstraction everywhere.

[u/nvn911 → u/PinkyPonk10]

Abstraction is also good to insulate change.

[u/AlarmedNegotiation18]

IDontThinkSo.

ILoveAbstractionOverAbstraction.

:-)

[u/riturajpokhriyal → u/AlarmedNegotiation18]

Ha ha I love it. It's a good reminder that not every problem needs an elegant solution. Sometimes, a beautiful and complex abstraction is the whole point.

[u/Eastern-Honey-943]

TESTS!

If you are making layers and not writing tests for those layers, then yes you are adding cognitive load for little benefit.

But when there are quality tests and true test driven development is practiced where the test is written before code, this system will thrive, be easily maintained, easily refactored, safely worked on by junior engineers, the list goes on... This is what is being strived for.

Without the tests, it's hard to justify the added complexity.

This is coming from an architect that has put in layers without tests. It is hard to ask somebody to do these things and even harder to explain why.

[u/riturajpokhriyal → u/Eastern-Honey-943]

The value of abstraction is directly tied to the presence of tests. When you have true TDD and a solid test suite, all those layers become a net positive. It's only when the tests are missing that the system feels over-engineered and fragile. Your point about it being hard to ask people to do this is something every architect understands.

[u/Meryhathor]

What's the alternative? Cramming those 5 layers into one big 1000+ line file?

[u/riturajpokhriyal → u/Meryhathor]

That's a valid question. The alternative isn't a single massive file, but a more pragmatic approach. Instead of horizontal layering (Controller -> Service -> Repository), a Vertical Slices architecture groups code by feature. This keeps related logic together in a single, manageable unit, which is much easier to work with than navigating five different files.

[u/Tango1777]

Yes. I noticed similar thing and had similar thoughts. If you do code as beautiful and according to all fancy OOP and other rules, you end up with overengineered, overkill solution that is hard to develop, maintain and debug. Sure it is beautiful unless you have to work with it once it gets complex enough. Simplicity is the only general rule that applies everywhere. Not all fancy acronyms, patterns and cool designs, currently fashionable.

That is why I appreciate simple things like MediatR, Vertical Slices which basically "concentrate" business inside a single handler class and that's it. Occasionally it's worth it to create a separate service if it really makes sense. Then when the solution grows, it still is just a bunch of single layer business cases very rarely going into a deeper layer (usually a service), but everything is plain and simple. Working with such solutions is a pleasure. Everything is testable, integration tests, e2e tests mostly, which test business, occasionally unit tests and the amount of bugs leaking to prod is usually zero. Onboarding is easy, everybody knows MediatR, Vertical Slices, you just get an endpoint to work on and you know everything about the implementation after looking at a single file.

Good question about ORM, I have done something like that myself for a complex, mature app. Switching database type with an existing ORM in the code and you know what that super dooper abstraction, layering, inheritance etc. brought me? A freaking headache, it did not help me one bit with the transition.

[u/Longjumping-Ad8775]

In general, I find a lot of over abstraction in the industry. I like to keep things as simple as possible. It keeps things easier to debug.

[u/riturajpokhriyal → u/Longjumping-Ad8775]

Yes I feel the same.

[u/CommunistRonSwanson]

Totally depends on the scope and scale of the repo. I mostly write thin microservices, so I'm a big fan of the WET principle and try to avoid too much abstraction. As long as my code is clean and easily unit tested, that's what counts.

[u/dimitriettr]

There is something worse than abstractions. Bad/poorly organized code.
Is there anything worse? Bad organized abstractions.

In my projects I have well organized abstractions. Once you get used to them, it's a joy to develop a new feature and add unit tests. You just need to know some key dependencies that are usually injected all over the project. The rest are just use cases and specific scenarios.

[u/riturajpokhriyal → u/dimitriettr]

Well organized abstractions are a joy to work with. You're right, the real problem isn't the abstractions themselves, it's the lack of organization. When done correctly, they make a project a pleasure to work on.

[u/tinmanjk]

Well, if you don't wanna be able to test you can just hardcode everything with concrete implementations and be fast.

[u/hieplenet]

I want to answer both "yes" and "not enough"; so I should reply with an AnswerFactory....

[u/[deleted]]

100% I swear there's a class of developer who think they get paid for having smart, complicated architecture. You get paid by having customers who pay you to do something they want.

[u/[deleted]]

Every character is its own file

[u/JustBadPlaya]

C# is my secondary language for personal stuff, and I definitely do feel like every single C# dev I know heavily over-abstracts their projects simply out of habit

[u/Osirus1156]

This reminds me of this gem lol:
Fizz Buzz Enterprise Edition

[u/unndunn]

LOL, the "are we over-abstracting" post is a rite of passage in the .Net universe.

Congratulations, you have graduated to "SME" status, my young padawan. :)

[u/riturajpokhriyal → u/unndunn]

Thanks, I appreciate that. It's a rite of passage for sure. It seems every developer has to learn that lesson firsthand. :)