Abstraction, in the general object-oriented sense, means hiding how something works and exposing only what it does. That definition is simple enough to fit in a textbook footnote — but in enterprise applications, it becomes one of the most consequential architectural decisions a team makes. Done well, it lets a system evolve for years without breaking. Done poorly (or not at all), every requirement change turns into a multi-team fire drill.
TL;DR — In enterprise systems, abstraction isn't about elegance, it's about survival. The interfaces you place at each layer boundary (data access, cache, secrets, external systems, and — critically, when other teams consume your API — the contract itself) are what let requirements change without breaking every team downstream. This article walks through a real layered C# design for an insurance platform, showing exactly where those seams should go, why "the database will never change" is a myth, and where teams tend to overdo it.
Let's walk through this using a concrete example: Safe Mode Insurance, a large insurance platform with a big customer base, multiple internal teams, and APIs shared with external integration partners.
The Scenario
Safe Mode Insurance needs a new API to accept and manage premium customer data, and this API will be consumed by other teams — some internal, some external integration partners.
A typical layered implementation looks like this — with the interface sitting explicitly at every boundary:
Color/role key: the contract layer (purple) protects external consumers from internal change · the service and repository (teal) hold core business logic · the three infrastructure dependencies (coral/blue/amber) are the swappable seams · the endpoints (gray) are neutral.
public interface IPremiumCustomerService
{
Task<PremiumCustomerDto> GetCustomerAsync(int id);
Task<PremiumCustomerDto> CreateCustomerAsync(CreatePremiumCustomerRequest request);
}
public class PremiumCustomerService : IPremiumCustomerService
{
private readonly IPremiumCustomerRepository _repository;
private readonly ICacheProvider _cache;
private readonly IExternalSystemClient _externalClient;
public PremiumCustomerService(
IPremiumCustomerRepository repository,
ICacheProvider cache,
IExternalSystemClient externalClient)
{
_repository = repository;
_cache = cache;
_externalClient = externalClient;
}
public async Task<PremiumCustomerDto> GetCustomerAsync(int id)
{
var cached = await _cache.GetAsync<PremiumCustomerDto>($"customer:{id}");
if (cached != null) return cached;
var customer = await _repository.GetByIdAsync(id);
var dto = MapToDto(customer);
await _cache.SetAsync($"customer:{id}", dto, TimeSpan.FromMinutes(10));
return dto;
}
private PremiumCustomerDto MapToDto(PremiumCustomer customer) => new()
{
Id = customer.Id,
Name = customer.Name,
PolicyTier = customer.PolicyTier.ToString()
};
}Because every dependency is injected as an interface, swapping the external system, the cache provider, or the key vault — becomes a registration change, not a rewrite:
// Before
builder.Services.AddScoped<ICacheProvider, RedisCacheProvider>();
builder.Services.AddScoped<ISecretVault, AzureKeyVaultProvider>();
// After the requirement change
builder.Services.AddScoped<ICacheProvider, InMemoryDistributedCacheProvider>();
builder.Services.AddScoped<ISecretVault, AwsSecretsManagerProvider>();PremiumCustomerService never changes. The other teams consuming your API never know the internal swap happened. That's the payoff.
| scenario | Note |
|---|---|
| Mocking the data layer during local debugging | Classic and one of the highest-value uses of abstraction |
| Changing external API calls | Very common — partner integrations change SDKs/endpoints often |
| Switching cloud storage providers | e.g., Azure Blob Storage → AWS S3, abstracted behind IFileStorageProvider |
| Switching the DB | mergers, cost optimization, CQRS read-model splits, regional data residency laws, scaling bottlenecks |
Additional Scenarios Worth Adding
1. Regional / regulatory business rule variation Insurance premium calculation rules often differ by state or country. Abstracting the rule engine behind a strategy interface avoids branching logic scattered across the codebase:
public interface IPremiumCalculationStrategy
{
decimal Calculate(PremiumCustomer customer);
}
public class USPremiumCalculationStrategy : IPremiumCalculationStrategy { }
public class EUPremiumCalculationStrategy : IPremiumCalculationStrategy { }A factory or DI-based resolver picks the right strategy per region at runtime — no if (country == "US") sprawl.
Join the conversation! Your thoughts help the community grow.