Why should you care?

ShopNest teams swap SQL Server for read replica or test doubles without rewriting checkout use cases in Domain.

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).

// Application
public interface IShopNestDbContext
{
    DbSet<Product> Products { get; }
    Task<int> SaveChangesAsync(CancellationToken ct);
}

// Infrastructure
public class ShopNestDbContext : DbContext, IShopNestDbContext { }

// Program.cs
builder.Services.AddScoped<IShopNestDbContext>(sp => sp.GetRequiredService<ShopNestDbContext>());

What happened?

• Application depends on IShopNestDbContext abstraction.
• Infrastructure implements with EF DbContext.
• Domain entities have zero EF references.

Practice next

1. Create Domain, Application, Infrastructure, Api projects.
2. Move ShopNestDbContext to Infrastructure.
3. Define repository or context interfaces in Application.
4. Extract AddInfrastructure(this IServiceCollection) extension method.
5. Replace IShopNestDbContext with specific repositories if boundaries tighten.

Remember

EF lives in Infrastructure outer ring. Application defines interfaces and use cases. Domain stays persistence ignorant.

ShopNest solution split

Monolith refactored into Clean Architecture — EF types never imported in Domain.csproj.

Outcome: Unit tests run on Application handlers without SQL installed.