When Design Patterns Become Rituals

Design patterns in .NET and ASP.NET Core teams often shift from deliberate solutions to unconscious habits — applied because they feel expected rather than because they solve a real problem. The post examines specific examples: the Repository pattern wrapping EF Core (which is already an abstraction), bloated Service classes with dependency inflation, reflexive interface creation, cargo-culted Factory patterns, and overuse of MediatR. The core argument is that patterns are trade-offs, not inherently good, and teams tend to accept their costs without evaluating whether the benefits apply. The antidote is restoring intentionality — always asking what specific problem a pattern solves before applying it — and trusting that ASP.NET Core's built-in features often provide sufficient structure without additional layering.