Abstraction is a powerful concept in software design

Abstraction is a powerful concept in software design, but over-abstraction can inadvertently harm your project. Here's a real experience from a .NET Core (C#) project.

-> The Problem: Abstraction Done Too Early
In one of our enterprise .NET Core applications, we aimed for “perfect architecture” and created multiple interfaces for a simple CRUD-based User module, including:
- IUserService
- IUserManager
- IUserProcessor
- IUserRepository
- IBaseRepository<T>
- IReadOnlyRepository<T>

Example:

public interface IUserService
{
 Task<UserDto> GetUserAsync(int id);
} 
public class UserService : IUserService
{
    private readonly IUserManager _userManager; 
    public UserService(IUserManager userManager)
    {
        _userManager = userManager;
    } 
    public async Task<UserDto> GetUserAsync(int id)
    {
        return await _userManager.GetUserAsync(id);
    }
}

This resulted in:
- No business logic
- Just method-to-method forwarding
- More files, more DI registrations, more confusion

-> Real Impact on the Project
- New developers took longer to understand the flow
- Debugging required jumping across 4–5 layers
- Change requests took more time
- “Flexible architecture” became hard to maintain

-> The Fix: Abstraction Where It Matters
We refactored by asking, “Is this abstraction solving a real problem today?”
What we kept:
- Repository abstraction (DB may change)
- Service layer only where business logic exists

-> What we removed:
- Pass-through interfaces
- Premature layers

-> Simplified version:

public class UserService
{
    private readonly UserRepository _repository;
    public UserService(UserRepository repository)
    {
        _repository = repository;
    }
    public async Task<UserDto> GetUserAsync(int id)
    {
        var user = await _repository.GetByIdAsync(id);
        if (!user.IsActive)
            throw new Exception("Inactive user");
        return MapToDto(user);
    }
}

- Clear
- Readable
- Easy to change
- Faster onboarding

-> Following are the important points:
- Abstraction is a tool, not a rule
- Don’t abstract until you see variation or change
- YAGNI still applies in modern .NET Core projects
- Simple code scales better than “clever” architecture

Good architecture evolves -> it is not forced on Day One.