Abstractions That Heal, Abstractions That Harm

Good abstractions reduce cognitive load and isolate change; harmful ones accumulate quietly and turn codebases into labyrinths. Using .NET and ASP.NET examples — interfaces, middleware, dependency injection, generic repositories, and Entity Framework — the post argues that abstractions should be introduced only when there are at least two concrete things to generalize across. Premature abstractions built on assumptions rather than evidence create the illusion of flexibility while actually constraining future change. Leaky abstractions like EF's lazy loading obscure rather than simplify. The quality of an abstraction reflects the depth of domain understanding behind it, and vague names like IServiceManager signal abstractions introduced before the domain was understood. The real danger is cumulative drift: individually reasonable layers that compound over time into a system no longer resembling the problem it solves.