Why should you care?

ShopNest checkout violating SRP by stuffing payment rules inside DbContext becomes untestable — SOLID keeps EF in Infrastructure while rules stay in Domain/Application.

See it live — copy this example

Paste into a .NET project with EF Core packages, then run with LocalDB/SQL Server (dotnet ef / dotnet run).

// DIP: depend on abstraction
public class ProductPricingService(IProductRepository products)
{
    public async Task<decimal> GetPriceAsync(int id, CancellationToken ct)
    {
        var p = await products.GetByIdAsync(id, ct)
            ?? throw new NotFoundException();
        return p.ApplyDiscount(); // domain method, not EF concern
    }
}

// SRP: DbContext only maps and persists
public class ShopNestDbContext : DbContext { /* no pricing rules here */ }

What happened?

• ProductPricingService depends on IProductRepository interface.
• DbContext never contains discount logic — Open/Closed via new handlers not editing DbContext.

Practice next

1. Audit DbContext for business logic — move to domain/services.
2. Replace direct DbContext injection in controllers with interfaces.
3. Split IOrderReadRepository from IOrderWriteRepository if interface grows fat.
4. Extract IProductCatalogQueries with read-only methods separate from writes.
5. Replace static helper on DbContext with injectable domain service.

Remember

DIP: Application depends on abstractions. SRP: DbContext persists; services decide. ISP: small focused repository interfaces.

ShopNest refactor review

Architect rejects PR adding tax calculation to ShopNestDbContext — moves to TaxService with IProductRepository.

Outcome: Tax rules unit-tested without EF InMemory.