Lessons in this course (8)
7. Folder structures for each app type at a glance
Small ASP.NET Core Web API (single project, feature-friendly):
Shop.Api/
├── Features/ or Controllers/ endpoints grouped by feature
├── Domain/ entities, enums, value objects
├── Data/ ShopDbContext, Configurations/, Migrations/
├── Services/ business services + interfaces
├── Contracts/ (Dtos/) request/response models
├── Infrastructure/ email, storage, external API clients
├── Middleware/ · Filters/ · Extensions/
├── Program.cs · appsettings*.jsonASP.NET Core MVC app (layered): Shop.Web (Controllers, Views, ViewComponents, wwwroot) + Shop.Application + Shop.Domain + Shop.Infrastructure (same layers as Clean Architecture, but the Web project has views).
Blazor Web App (.NET 8+): Shop (server project: Components/ with App.razor, Routes.razor, Layout/, Pages/, Program.cs) + Shop.Client (WebAssembly project for interactive components) + shared libraries.
Worker / background processing: Shop.Worker (Worker.cs BackgroundService classes, Program.cs with Host.CreateApplicationBuilder) reusing Application/Infrastructure projects.
.NET Framework legacy (Web Forms / MVC 5): Shop.Web (pages/controllers, App_Start, Global.asax, Web.config) + Shop.BLL + Shop.DAL + Shop.Entities + Shop.Common.
Full stack monorepo:
repo/
├── src/ Shop.Api · Shop.Application · Shop.Domain · Shop.Infrastructure · Shop.Worker · Shop.AppHost (Aspire)
├── web/ shop-ui/ (Angular: src/app/core, shared, features/orders, ... | React: src/components, pages, hooks, services, store)
├── tests/ · deploy/ · docs/ · .github/workflows/Rule of thumb: group by feature at the top level when the app grows; keep technical sub-folders inside a feature only if they help.