Roadmap › 1. .NET › Step 25
Arc
.NET Project Architectures & Folder Structures — Layered, Clean, Onion, Vertical Slice
How real .NET solutions are organised — solution and project structure, 3-tier and N-layer architecture, Onion, Hexagonal (ports and adapters) and Clean Architecture, Vertical Slice architecture, modular monolith, DDD building blocks, CQRS, the folder structure of each style with naming conventions, shared build settings (Directory.Build.props, central package management), test projects, where cross-cutting concerns live, and how to choose an architecture.
What it is & where it is used
Architecture = how code is split into parts, what each part is responsible for, and which parts may depend on which. A good structure makes code easy to find, change, test and deploy.
| Style | Core idea | Typical fit |
|---|---|---|
| 3-tier / N-layer | UI → Business (BLL) → Data (DAL) | Classic enterprise apps, Web Forms/MVC 5 |
| Onion / Clean / Hexagonal | Domain at the centre; infrastructure and UI depend inward on interfaces | Medium–large apps with real business logic, long life |
| Vertical Slice | Organise by feature (one folder per use case), not by technical layer | APIs with many independent features, CQRS |
| Modular monolith | One deployable, split into independent modules | Growing products; stepping stone to microservices |
| Microservices | Separate deployable services per business capability | Large organisations (see the Microservices course) |
Versions & history
| Year | Milestone |
|---|---|
| 1990s | Client/server, then 3-tier architecture |
| 2002 | Fowler's Patterns of Enterprise Application Architecture (layers, repository, unit of work) |
| 2003 | Domain-Driven Design (Eric Evans) |
| 2005 | Hexagonal architecture / ports and adapters (Alistair Cockburn) |
| 2008 | Onion architecture (Jeffrey Palermo) |
| 2010 | CQRS popularised (Greg Young) |
| 2012 | Clean Architecture (Robert C. Martin) |
| 2018 | Vertical Slice architecture (Jimmy Bogard) |
| 2020s | Modular monoliths; templates: Jason Taylor's CleanArchitecture, Ardalis CleanArchitecture; .NET Aspire solution layouts; .slnx solution format (VS 2022 17.13+/.NET 9 SDK) |
Lifecycle
How a request flows through a Clean Architecture ASP.NET Core API:
text
HTTP request
→ Api (controller / minimal endpoint, model binding, auth) [Presentation]
→ Application (use case / command handler, validation, DTO mapping) [Application]
→ Domain (entities enforce business rules, domain events) [Domain — no dependencies]
→ Application calls interfaces (IOrderRepository, IEmailSender, IClock)
→ Infrastructure implements them (EF Core DbContext, SMTP, Azure Blob) [Infrastructure]
→ database / external services
← result → DTO → HTTP responseDependency rule: source-code dependencies point inwards (Api → Application → Domain; Infrastructure → Application/Domain). The Domain knows nothing about EF Core, ASP.NET or SQL.
Tools used to develop
dotnet new sln,dotnet new classlib/webapi/xunit,dotnet sln add,dotnet add reference.- Templates:
Clean.Architecture.Solution.Template(Jason Taylor),Ardalis.CleanArchitecture.Template, .NET Aspire starter. - Architecture tests: NetArchTest, ArchUnitNET (enforce "Domain must not reference Infrastructure").
- Visual Studio dependency diagrams / code maps, NDepend.
- Diagrams: C4 model, draw.io, Structurizr.