Layered and clean architecture in a .NET solution — .NET Full Stack Developer Interview

9. Layered and clean architecture in a .NET solution

Advanced★ Must knowLesson 9 of 10

A common, interview-friendly solution layout:

text

src/
  Shop.Domain/          entities, value objects, domain rules        (no dependencies)
  Shop.Application/     use cases/services, DTOs, interfaces (IOrderRepository), validation
  Shop.Infrastructure/  EF Core DbContext, repositories, email, file storage, external APIs
  Shop.Api/             controllers/endpoints, DI wiring, middleware, auth
tests/
  Shop.UnitTests/  Shop.IntegrationTests/
web/
  shop-ui/              Angular or React app

Dependency rule: dependencies point inwards — Api → Application → Domain; Infrastructure implements interfaces defined in Application. That is the Dependency Inversion Principle in practice, and it is what makes services unit-testable (mock IOrderRepository).

Question	Answer
Do I need a repository over EF Core?	`DbContext` already is a unit of work and `DbSet` a repository. Add your own repository when you want to hide EF from the application layer, share query logic or ease testing; avoid generic repositories that just wrap `DbSet`.
Where does validation go?	Input shape in the API (FluentValidation), business rules in Application/Domain, integrity in the database.
Monolith or microservices?	Start with a modular monolith; split a module into a service only when it needs independent scaling, deployment or ownership.
CQRS?	Separate read models (fast queries, often Dapper/SQL views) from write models (rich domain + EF). Useful when reads and writes have very different needs; MediatR is optional.