When should you not introduce an abstraction in a .NET codebase, and how do you decide whether an interface or base class is earning its keep?

1. Where "interface everything" came from

Modern alternatives reduce the need: TimeProvider/FakeTimeProvider, FakeLogger, HttpMessageHandler stubs (or WireMock.Net), WebApplicationFactory for in-process API tests, and Testcontainers (throwaway real databases/brokers in Docker for integration tests).

2. Leaky abstractions

Joel Spolsky: "All non-trivial abstractions, to some degree, are leaky." A repository over EF Core still leaks:

• change tracking and SaveChanges semantics,
• lazy/eager loading and N+1 risks,
• query translation limits (what can and can't become SQL),
• transaction scope and concurrency behaviour.

Callers must understand EF Core anyway, so the wrapper mostly removes features (projections, AsNoTracking, ExecuteUpdateAsync, split queries) without hiding complexity.

3. Rule of three for abstractions

At architectural boundaries (vendors, I/O), abstract from the start: the boundary itself is the reason, not the number of implementations.

4. Measuring abstraction health

5. Removing abstractions safely

1. List single-implementation interfaces; exclude boundary ports and public library extension points.
2. For each, register the concrete type in DI (AddScoped<OrderQueries>()), switch consumers to the concrete type, delete the interface.
3. Replace mocks with real objects, fakes of real boundaries, or integration tests.
4. Do it module by module in small PRs; behaviour shouldn't change.

6. Base classes deserve the same scrutiny

A BaseService<T> shared by unrelated features accumulates protected hooks and virtual methods; subclasses depend on its internals (fragile base class problem). Prefer composition (inject the shared collaborator) unless subclasses are true specialisations that honour the base's contract (LSP).

7. Try it yourself

1. Count interfaces vs implementations in your solution.
2. List single-implementation interfaces not at a boundary.
3. Inline one; note whether any test genuinely got harder (vs just needing a different style).
4. Replace an IClock wrapper with TimeProvider and FakeTimeProvider.
5. Rewrite a repository-heavy query using DbContext with a projection and compare the SQL and performance.

using Microsoft.EntityFrameworkCore;
using Microsoft.Extensions.Time.Testing;

// No IOrderQueries interface: one implementation, used inside one module.
public sealed class OrderQueries(ShopDb db)
{
    public Task<List<OrderSummary>> RecentAsync(int customerId, CancellationToken ct) =>
        db.Orders
          .Where(o => o.CustomerId == customerId)
          .OrderByDescending(o => o.PlacedAt)
          .Select(o => new OrderSummary(o.Id, o.Total))   // EF Core projection still available
          .Take(20)
          .ToListAsync(ct);
}

// TimeProvider is already an abstraction; no IClock wrapper needed.
public sealed class TrialPolicy(TimeProvider time)
{
    public bool IsExpired(DateTimeOffset startedAt) => time.GetUtcNow() > startedAt.AddDays(14);
}

// Abstraction that does earn its keep: an architectural port to a vendor.
public interface ISmsSender { Task SendAsync(string to, string message, CancellationToken ct); }

public sealed record OrderSummary(int Id, decimal Total);
public sealed class Order { public int Id { get; set; } public int CustomerId { get; set; } public decimal Total { get; set; } public DateTimeOffset PlacedAt { get; set; } }
public sealed class ShopDb(DbContextOptions<ShopDb> o) : DbContext(o) { public DbSet<Order> Orders => Set<Order>(); }

public static class Demo
{
    public static void Main()
    {
        var fake = new FakeTimeProvider(new DateTimeOffset(2026, 10, 23, 0, 0, 0, TimeSpan.Zero));
        var policy = new TrialPolicy(fake);
        Console.WriteLine(policy.IsExpired(fake.GetUtcNow().AddDays(-15))); // True
    }
}

Requires Microsoft.EntityFrameworkCore and Microsoft.Extensions.TimeProvider.Testing.